SCCM под угрозой: как находить и устранять ошибки конфигурации
Microsoft Configuration Manager, ранее известный как System Center Configuration Manager, позволяет централизованно управлять рабочими станциями, серверами, приложениями, обновлениями и политиками безопасности. По данным BI.ZONE SOC, решение используется примерно в четверти российских организаций, главным образом в крупных компаниях с большим количеством пользователей и устройств.
Широкие полномочия делают SCCM не только удобным инструментом администрирования, но и привлекательной целью для атакующих. Если злоумышленник получает контроль над системой управления, он способен:
- получить административные права на конечных устройствах;
- перемещаться между сегментами сети;
- собирать сведения о пользователях, серверах и рабочих станциях;
- выполнять произвольный код;
- изменять политики безопасности и параметры соответствия;
- закрепляться в инфраструктуре под видом штатных операций обслуживания.
Особую опасность представляют учетные записи, применяемые SCCM для установки клиента и выполнения команд. Обычно они обладают локальными административными правами на компьютерах, а иногда имеют расширенные разрешения в Active Directory. При этом атакующему не всегда требуется захватывать сам сервер Configuration Manager: некоторые ошибки настройки позволяют получить привилегированные учетные данные или выполнить вредоносные действия через отдельные компоненты системы.
Безопасная архитектура SCCM
Защиту необходимо закладывать еще на этапе проектирования. Сервер сайта, SMS Provider и сервер базы данных сайта желательно размещать в наиболее защищенном сегменте инфраструктуры, сопоставимом с зоной Tier 0. Эти компоненты хранят критически важную информацию и обеспечивают работу всего комплекса, поэтому прямой доступ клиентских устройств к ним следует исключить.
Компоненты, с которыми непосредственно взаимодействуют рабочие станции, не стоит объединять на одном сервере с центральными ролями SCCM. Для компьютеров, подключающихся из интернета, необходимо использовать выделенные серверы в DMZ. Внешние устройства не должны обслуживаться через те же узлы, которые управляют внутренними компьютерами.
Межсетевые правила следует строить по принципу минимально необходимого доступа. Нужно разрешить только те порты и протоколы, которые требуются конкретным ролям SCCM. Широкие правила "для любой сети" усложняют контроль и увеличивают последствия компрометации одного из компонентов.
Минимальные привилегии для служебных учетных записей
Каждая учетная запись SCCM должна обладать только теми правами, которые нужны ей для выполнения конкретной задачи. Не следует использовать доменные учетные записи администраторов в качестве сервисных, а также назначать им права Domain Admin без крайней необходимости.
Рекомендуется разделять учетные записи для разных операций: установки клиентов, доступа к базе данных, публикации приложений и администрирования. Для них нужно включать многофакторную аутентификацию там, где это поддерживается, ограничивать интерактивный вход и регулярно проверять фактическое использование разрешений.
Ошибки при развертывании операционной системы
Незащищенная PXE-инфраструктура
PXE-загрузка позволяет устанавливать операционные системы по сети, но при неправильной настройке может стать способом получить доступ к корпоративным образам, скриптам и служебным учетным данным. PXE-серверы следует изолировать, ограничить доступ к ним на уровне коммутаторов и межсетевых экранов, а сетевую загрузку разрешать только в специально выделенных сегментах.
Не стоит оставлять поддержку неизвестных устройств включенной без необходимости. В противном случае любой компьютер, подключенный к соответствующему сегменту, может попытаться получить загрузочный образ и пройти процедуру установки.
Дополнительный риск возникает при отсутствии пароля или другого механизма защиты PXE-загрузки. Если бизнес-процесс допускает, необходимо применять пароль, сертификат либо предварительную регистрацию устройств. Также важно контролировать содержимое загрузочных образов: в них не должны храниться пароли, токены и другие секреты в открытом виде.
Установка клиента через Client Push
Механизм client push удобен, поскольку позволяет автоматически устанавливать агент SCCM на компьютеры домена. Однако его работа часто связана с использованием привилегированной учетной записи. При компрометации этой учетной записи атакующий может установить агент на произвольный компьютер и использовать его для выполнения команд с административными правами.
Безопаснее отказаться от безусловного применения client push и использовать его только для заранее определенных коллекций устройств. Учетную запись следует ограничить по области действия, запретить ей интерактивный вход и исключить повторное использование пароля в других службах.
Защита TLS-соединений
Передача данных между клиентами, точками распространения и точками управления без шифрования позволяет перехватывать учетные данные, политики и содержимое служебных запросов. Для критичных соединений необходимо включить HTTPS и использовать сертификаты, выданные доверенным корпоративным удостоверяющим центром.
Особое внимание следует уделить точкам распространения ПО. Если клиент получает приложения по незащищенному протоколу, атакующий в сети может попытаться подменить содержимое или внедрить вредоносный файл. Точка управления клиентами также должна работать через защищенный канал, чтобы политики и команды не могли быть изменены при передаче.
Следует отключать устаревшие версии TLS и слабые наборы шифров, контролировать срок действия сертификатов и заранее организовать их автоматическую замену. Ошибка в цепочке доверия часто приводит к тому, что администраторы временно возвращаются к небезопасному HTTP.
Аутентификация устройств и одобрение клиентов
Если SCCM принимает подключения от клиентов без проверки подлинности, атакующий может попытаться зарегистрировать поддельное устройство. Более надежный вариант - использовать PKI-сертификаты и взаимную аутентификацию клиента и сервера.
Автоматическое одобрение всех устройств также создает значительный риск. Новые клиенты должны проходить проверку по имени, сертификату, принадлежности к домену или другой заранее определенной процедуре. Особое внимание требуется уделять компьютерам, которые появляются в системе после переустановки или смены владельца.
Управление приложениями и удаленный доступ
Приложения, устанавливаемые через SCCM, нередко запускаются от имени SYSTEM. Если пакет содержит интерактивный установщик, пользователь может получить доступ к процессу с повышенными правами или повлиять на его выполнение. Поэтому приложения следует проектировать как полностью автоматизированные, проверять используемые скрипты и исключать пользовательский ввод во время привилегированной установки.
Удаленное подключение к рабочим станциям должно выполняться только с явным подтверждением пользователя, если это не противоречит утвержденной процедуре реагирования. Режим скрытого управления существенно облегчает злоумышленнику работу на скомпрометированном компьютере и затрудняет расследование инцидента.
На самих клиентах необходимо проверить политики удаленного управления. Запрет подтверждения со стороны пользователя следует применять только там, где это оправдано, например на серверных системах с круглосуточным обслуживанием. Для рабочих станций лучше использовать уведомления, журналирование и ограничение доступа по группам администраторов.
Локальный кэш клиента
Каталог кэша SCCM может содержать установочные файлы, скрипты и временные данные приложений. Избыточные права на эту папку позволяют обычному пользователю изменить содержимое пакета или подменить исполняемый файл перед запуском с повышенными привилегиями.
Разрешения NTFS должны быть минимальными: пользователь не должен иметь возможности изменять файлы, подготовленные для установки от имени SYSTEM. Следует также контролировать права на родительские каталоги, временные папки и места хранения логов.
Дополнительная защита окружающей инфраструктуры
Безопасность SCCM зависит не только от настроек самой платформы. База данных, Active Directory, удостоверяющий центр и файловые сервисы могут стать путем к ее компрометации.
SQL Server необходимо обновлять, изолировать от клиентских сегментов, ограничивать доступ к экземплярам и применять отдельные учетные записи для служб. Важно отслеживать необычные подключения, изменения ролей и попытки извлечения данных.
Использование NTLM следует поэтапно сокращать, заменяя его Kerberos и другими современными механизмами. В доменной среде нужно включать аудит аутентификации и выявлять устройства, которые продолжают обращаться к устаревшему протоколу.
Удостоверяющий центр требует отдельной защиты. Сертификаты, применяемые SCCM для взаимной аутентификации, фактически определяют доверие к устройствам. Компрометация шаблона сертификата может позволить получить расширенные права в домене, поэтому необходимо ограничить выдачу сертификатов, убрать лишние права на шаблоны и контролировать операции регистрации.
LDAP следует использовать с защищенным каналом и обязательной подписью. Для SMB желательно включить подписание, чтобы снизить риск подмены трафика и атак посредника. Службу WebClient, если она не требуется бизнес-процессам, лучше отключить: она может использоваться для обращения к удаленным ресурсам и передачи учетных данных.
Контроль и автоматическое выявление проблем
Проверку конфигурации SCCM нужно проводить регулярно, а не только после внедрения. Полезно составить перечень контролей: состояние TLS, настройки PXE, права служебных учетных записей, режим одобрения клиентов, доступность HTTP, разрешения на кэш и параметры удаленного управления.
Автоматизированный аудит позволяет быстрее замечать появление новых устройств, изменение ролей, ослабление сетевых правил и выдачу опасных разрешений. Результаты проверок следует передавать в SIEM или другую систему мониторинга, чтобы события сопоставлялись с активностью в Active Directory, SQL Server и на конечных устройствах.
Не менее важны резервное копирование конфигурации, план восстановления и регулярные учения. Организация должна заранее понимать, как отключить скомпрометированную учетную запись, изолировать сервер сайта, заменить сертификаты и восстановить управление клиентами без массового простоя.
SCCM становится безопасным не за счет одной настройки, а благодаря совокупности мер: сегментации сети, минимальным привилегиям, обязательному шифрованию, строгой проверке клиентов, защите PXE и постоянному аудиту. Чем шире полномочия платформы, тем важнее относиться к ней как к критическому компоненту корпоративной инфраструктуры, а не просто к инструменту установки программ.