Про RedCheck с web-интерфейсом и агентное сканирование Windows. Занимался на днях разворачиванием и тестированием RedCheck-а. В принципе всё норм. Единственное, что при установке с Web-интерфейсом и Rest API требуется выполнить довольно много ручных операций:
1. Установка СУБД и создание пользователя
2. Установка Web-сервера IIS
3. Установка Microsoft .NET Framework
4. Установка Microsoft .NET Core
5. Установка серверного компонента
6. Установка консоли управления (пользовательского интерфейса)
7. Включение возможности Windows-авторизации*
8. Включение обработки HTTPS-соединений*
9. Установка службы синхронизации
10. Установка службы сканирования
Кажется, что большую часть операций можно было бы засунуть в один инсталлер. Но понятное дело, что таких доработок делать не будут, т.к. у АЛТЭКС-СОФТа сейчас в первую очередь стоит задача миграции на Linux. В целом, руководство по установке понятное и подробное. Только в одном месте была проблема с ошибкой в PowerShell-скрипте, но надеюсь поправят. Инсталлеры самих компонентов RedCheck удобные, по сути жмёшь "далее-далее". Часть операций (со *) я пропустил, т.к. для теста это не требовалось.
Теперь про агентное сканирование. Это вообще так себе термин, потому что под ним можно понимать разное:
1. Ставишь агент на таргет-хост, агент сам подключается к серверу (облачному или on-prem) и либо сам отдаёт в него какие-то данные для анализа, либо забирает у него какие-то задачки на выполнение и отдаёт результаты. Профит, что вообще не нужно париться учётками и тем доступен ли сейчас таргет-хост в сети для сканирования или нет (в первую очередь ноутбуков касается). Так работает Qualys, Tenable, Defender for Endpoint.
2. Ставишь агент на таргет-хост, агент сам ничего не делает, но когда к нему подключается сервер, то он делает аутентификацию через этого агента с использованием некоторых внутренних сертификатов. Также профит к том, что не нужно париться доменными учётками и их возможными утечками. Так работает Scan Assistant от Rapid7.
3. Ставишь агент на таргет-хост, агент сам ничего не делает, но когда к нему подключается сервер, то аутентификация проходит через локальную учётку хоста или доменную учётку. В этом случае по сути просто реализуется альтернатива традиционным безагентным транспортам WMI и WinRM.
И вот в RedCheck реализуется именно третий тип агентного сканирования. Позиционируется он так:
"Агент сканирования – компонент RedCheck, предназначенный для сканирования хостов, ограниченных политикой ИБ организации (например, запрет или ограничение использования WMI, WinRM, отсутствие возможности использовать УЗ администратора), а также для обеспечения быстродействия и повышенной надёжности сканирования. Данный компонент работает только по запросу от сервера сканирования в рамках назначенной задачи аудита."
Плюсом тут идёт быстрота, экономия канала и максимальная функциональность проверок. Сканирование идёт от имени Системы. Но для подключения учётка (локальная или доменная) всё равно нужна. Эта учётка может не иметь права администратора на хосте, но она должна быть в группе REDCHECK_ADMINS. То есть риски компрометации такой учётки будут ниже, но было бы удобнее, если бы она вовсе не требовалась. С другой стороны, в таком случае появлялись бы вопросы к процедуре аутентификации сервера на таргет-хосте с агентом, всё-таки порт агента наружу выставлен и это теоретически возможный вектор атаки. Процесс аутентификации по учётке всё-таки проще и прозрачнее. В общем, здесь вопрос спорный. 🙂 Ну и, независимо от способа аутентификации, просканировать с помощью такого "транспортного" агента можно будет только те хосты, до которых мы сможем дотянуться непосредственно во время выполнения задачи сканирования, т.е. основная проблема безагентных сканов остаётся.
Поэтому имейте в виду возможные варианты реализации агентного сканирования на уязвимости и заранее задавайте вопросы VM-вендорам. 😉
