Как строить сканирование активов в MaxPatrol VM. Ч.1 — LDAP

Добрый день, немногочисленные дамы и многочисленные господа узкого мира ИБ!

Представляюсь по случаю написания первой статьи на Хабр! Меня зовут Аристов Никита, я руковожу практикой Управления уязвимостями инфраструктуры в «Газпром ЦПС», являюсь лидером Процесса как внутри нашей организации, так и у наших клиентов.

Кто-то, может, меня уже знает, однажды судьба приказала мне выступать с докладом на конференции «СФЕРА Cybersecurity», которую организовывал мой предыдущий работодатель. Там я рассказывал о том, как мы с Романом Журавлевым @RNZH с нуля внедряли MaxPatrol VM, запись можно посмотреть на Rutube.

Теперь меня совершенно добровольно заставили переносить свой личный опыт в статьи на Хабр. В моих статьях не будет ИИ-генерации текста, маркетинга «почему вам это нужно», рекламы вендоров, продвижения услуг (даже наших собственных), организации курсов, а лишь суровая правда с полей войны за безопасность инфраструктуры.

Область применимости

Сразу отмечу, что мои статьи предназначены для организаций, которые созрели к Vulnerability Managment. Не для реального малого бизнеса — дяди Пети, владельца фуры и работающего на перевозках квартир. У которого чёрная бухгалтерия, а из IT — телега и аккаунт у агрегатора. Но он не ИП — он нанимает своего молодого зятя подработать грузчиком, пока тот учится в институте. Цитата взята отсюда.

В качестве основого ПО я использую MaxPatrol VM от Positive Technologies, так исторически сложилось — фух, оправдался.

Колесо сансары

В своей работе я предпочитаю использовать цикл Деминга (PDCA) по RBVM (Risk-Based Vulnerability Management). В отличие от освященной методики ФСТЭК 2023, RBVM ставит Инвентаризацию ИТ-активов в начальный этап Процесса. Я с этим полностью согласен, считаю, что без проведенной инвентаризации подступаться к уязвимостям бесполезно (в явном виде наша организация не обязана слепо подчиняться методике ФСТЭК, так что имею мнение, хоть и ошибочное (ИМХО)). Да и методика ФСТЭК не раскрывает подробностей что делать, если сканер находит Shadow IT и инфраструктуру злоумышленника, в самом худшем сценарии. К тому же, RBVM в инвентаризации активов закладывает определение критичности ИТ-активов, а это означает, что контекстные метрики CVSS заходят в чат.

Начнем цикл статей с начала построения Процесса управления уязвимостями инфраструктуры. А Процесс начинается с Инвентаризации ИТ-активов, в нашем случае с получения информации о собственной инфраструктуре/об инфраструктуре заказчика, доменных ИТ-активах.

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

Официальная документация

Обратимся к документации, предоставляемой вендором.

Официальная документация по импорту из Microsoft Active Directory. В целом этой инструкции вполне достаточно для запуска импорта активов из MS AD. Но дальше разговор будем вести о нюансах.

В списке поддерживаемого ПО вендор заявляет о поддержке всех версий Microsoft Active Directory, что не может не радовать. Бонусом мы получаем поддержку Samba-DC/Samba-AD (на Samba строятся отечественные каталоги РЕД АДМ, Альт Домен), Samba эмулирует работу контроллеров домена Windows 2008 R2. Службы каталогов на базе FreeIPA (православный ALD Pro) не поддерживаются из коробки.

Права учетной записи в AD

Для чтения леса домена требуются базовые права, достаточно стандартных прав «Пользователя домена». Именно для сбора по LDAP не требуется прав Администратора домена. Но если Вы планируете собирать учетные записи в AD, то я рекомендую делегировать права Read All Properties (чтение всех свойств) для сбора атрибутов userAccountControl (UAC), что позволит MPVM видеть статус УЗ заблокирована/активна.

В век нейросетей меня наругали за позицию отрицания нейросетей при написании этой статьи. Развивающая обратная связь понятна и конструктивна, исправляюсь и предоставляю промт для Alisa AI по написанию скрипта делегирования полномочий для нашей учетной записи:

Делегировать через PowerShell для учетной записи полномочия на чтение атрибутов UAC в Active Directory

Скрипт, который она сгенерировала (я не проверял его работоспособность!):

Способ через PowerShell (наиболее точный и воспроизводимый)Этот метод позволяет гибко задать именно право на чтение нужных атрибутов.Подготовка1. Модуль: Убедитесь, что установлен модуль ActiveDirectory (Import-Module ActiveDirectory).2. Права: Скрипт должен запускаться от имени пользователя с правами на изменение ACL в целевой OU (обычно член группы Domain Admins или делегированный администратор).3. GUIDы: Для делегирования прав в AD используются GUIDы классов объектов и прав доступа.    * GUID класса User: bf967aba-0de6-11d0-a285-00aa003049e2    * Право на чтение всех свойств: 00000007-0000-0000-c000-000000000000 (GUID права Read All Properties).Скрипт делегирования    # 1. Параметры    $TargetOU = "OU=Users,DC=contoso,DC=com" # Замените на DN вашей OU    $DelegateAccount = "CN=HelpDeskUser,OU=Admins,DC=contoso,DC=com" # DN учетной записи, которой даем права    $AccountObject = Get-ADUser -Identity $DelegateAccount -Properties SID    $SID = New-Object System.Security.Principal.SecurityIdentifier($AccountObject.SID)    # 2. GUIDы    $UserClassGuid = [GUID]"bf967aba-0de6-11d0-a285-00aa003049e2"    $ReadAllPropertiesGuid = [GUID]"00000007-0000-0000-c000-000000000000"    # 3. Получаем текущий ACL OU    # Используем провайдер AD:\ для работы с ACL    $ACL = Get-ACL "AD:\$TargetOU"    # 4. Создаем правило доступа    # Allow = разрешить, ReadAllProperties = чтение всех свойств, Descendents = для дочерних объектов (пользователей внутри OU)    $Rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule `        ($SID, "ReadProperty", "Allow", $ReadAllPropertiesGuid, "Descendents", $UserClassGuid)    # 5. Добавляем правило и применяем    $ACL.AddAccessRule($Rule)    Set-ACL -Path "AD:\$TargetOU" -AclObject $ACL    Write-Host "Права успешно делегированы для OU: $TargetOU"Что делает этот скрипт:1. Берет SID целевой учетной записи.2. Создает правило, разрешающее чтение всех свойств (ReadProperty с GUID Read All Properties) для объектов класса User.3. Применяет это правило ко всем потомкам (Descendents) указанной OU. Это значит, что пользователь сможет читать атрибуты (включая userAccountControl, который и есть настройки UAC) у всех пользователей внутри этой папки.Важно: Если вы хотите дать право читать только атрибут userAccountControl, а не все свойства, нужно использовать GUID конкретного атрибута вместо ReadAllProperties.    * GUID атрибута userAccountControl: bf967a9c-0de6-11d0-a285-00aa003049e2.    * Тогда в коде замените $ReadAllPropertiesGuid на этот GUID, а тип права оставьте ReadProperty.

Задача на LDAP-сканирование

Напоминаю, что официальной документации от вендора вполне достаточно, чтобы запустить сканирование по LDAP.

Но здесь не просто так вендор предлагает разбить задачу сбора на 3 части по типам собираемых объектов:

1. Сбор списка компьютеров.

2. Сбор групп пользователей.

3. Сбор списка групп.

Я очень рад, что эта моя личная боль появилась в официальной документации. Мне частенько снится в страшных снах день, когда синхронизация по LDAP остановилась. Потому что вес актива Active Directory внутри БД достиг нескольких десятков гигабайт, и дальше не хватало маны, чтобы обработать обновление AD внутри MPVM. Актив Active Directory не очищается, как остальные активы, сколько не выставляй ограничение хранения истории активов в параметре HistoryRotationDepth роли Core. А с раздельным сбором у меня эта проблема с весом актива в БД больше не воспроизводилась.

Для собственной организации хорошая практика собирать целиком дерево домена, но для наших заказчиков мы собираем только объекты Computers. Пользователей и группы не собираем. Почему? Вопрос договоренностей. Мне не хочется гадать на бумажной гуще является ли Active Directory сторонней организации ИСПДн или не является, нужно ли включать в договор соглашение о передаче ПДн сотрудников организации, будет ли заказчик собирать согласия с сотрудников на передачу ПДн к нам и придумывать LDAP-фильтры, чтобы исключить сотрудников не подписавших согласие. Я в этих ПДн ничего не понимаю, а от А4 у меня голова болит. Я при общении с заказчиками задаю вопрос «Надо»? Если не надо — не делаю. Если надо, зову коллег, которые говорят, что шарят в этой теме.

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

ОС коллектора

Казалось бы, причем тут выбор ОС коллектора и сканирование по LDAP? Но на самом деле вся статья только ради этого и затевалась. Сейчас мне снится в страшных снах уже другой день, когда синхронизация по LDAP остановилась. Некоторое время назад, мы с коллегами озаботились безопасностью MS AD. Одним из пунктов нашего плана был полный отказ от незашифрованного LDAP, переход на LDAPS.

При разборе полетов мы проверяли сценарии подключения через ldapsearch, меняли учетные записи для подключения, формат записи УЗ, собирали тонны логов, разработчики переписывали библиотеки, они же расширяли штатное логирование, трясли krb5.conf, обновляли-откатывали платформу, ломали по LDAP в принципе, ставили экспериментальные сборки сканера, выпускали-перевыпускали keytab’ы, дружно ничего не понимали. В общем диагностировали, диагностировали да продиагностировали — проблема оказалась на стороне сканера. И она воспроизводится если для контроллеров домена политика Domain controller: LDAP server channel binding token requirements установлена в Always. Если переводим политику в When supported, то синхронизация с доменом завершается успешно.

Было выдвинуто предположение, что могут помочь манипуляции (даже для DC старше Windows Server 2003) из статьи, но этот способ не работает из-за зависимостей, в том числе зависимостей самого MaxPatrol.

Причем PT MC, через который проходит авторизация в MPVM под доменными УЗ, нормально работает с этой настройкой. Ждем от вендора доработки, да вот незадача:

Ну значит, остается только ждать и ходить по LDAPs на контроллеры с коллектора на ОС Windows. Ну или из рубрики «Плохие советы»: либо понижать уровень безопасности домена, либо не собирать домен вовсе.

Отдельно хочу выразить благодарность ребятам из PT, которые вместе со мной проходят по пути траблшутинга! ❤️