MaxPatrol EDR Getting Started: первый шаг к защите конечных узлов
Настройка в пользовательском интерфейсе
После установки MaxPatrol EDR переходим к его настройке через веб-интерфейс. В этой статье разберём весь процесс — от создания групп агентов до выбора сценария использования продукта.
Порядок настройки MaxPatrol EDR
Настройка выполняется последовательно в пять шагов:
- Создать группы агентов.
- Распределить агенты по группам.
- Настроить задачи в планировщике для автоматизации операций с агентами.
- Создать политики — добавить и настроить в них необходимые модули.
- Применить политики к группам агентов.
Группы агентов
Группа агентов — базовая единица управления в MaxPatrol EDR. Это набор устройств, объединённых по произвольному признаку: подразделению, роли, сегменту сети, географии, уровню критичности. Именно группе назначаются политики — а значит, все агенты в группе получают одинаковый набор модулей и настроек.
Важно учитывать: каждый агент может входить только в одну группу (или не принадлежать ни к одной). При добавлении агента в группу все назначенные ей политики применяются к нему автоматически.
В системе есть встроенные группы-шаблоны.
Важно учитывать: каждый агент может входить только в одну группу (или не принадлежать ни к одной). При добавлении агента в группу все назначенные ей политики применяются к нему автоматически.
В системе есть встроенные группы-шаблоны.
Рисунок 1. Шаблоны групп агентов
При необходимости создайте собственную: Группы агентов → Создать группу.
При необходимости создайте собственную: Группы агентов → Создать группу.
Рисунок 2. Создание группы агентов
Параметры группы агентов
Метки — используются для быстрого поиска и фильтрации. Можно выбрать существующие или создать новые.
Источник системных событий — определяет, куда отправляются системные события со всех агентов группы:
Типы событий в MaxPatrol EDR
Параметры кэша — максимальный размер и время хранения событий на агенте при потере связи с сервером. При восстановлении соединения накопленные события автоматически отправляются. События ИБ кэшируются всегда, независимо от настроек группы.
Ограничение скорости — максимальная скорость передачи данных в обоих направлениях (агент ↔ сервер агентов). Критически важный параметр для инфраструктур с узкими каналами связи.
Перемещение агентов между группами
Агента можно перенести из одной группы в другую в любой момент. При этом с устройства удаляются все модули, установленные через политики исходной группы, и автоматически устанавливаются модули из политик новой группы (с учётом совместимости с ОС и версией агента).
Параметры группы агентов
Метки — используются для быстрого поиска и фильтрации. Можно выбрать существующие или создать новые.
Источник системных событий — определяет, куда отправляются системные события со всех агентов группы:
Значение | Поведение |
Не отправлять | Системные события никуда не отправляются |
Только на сервер агентов | События отправляются по syslog (при наличии в политике модуля «Отправка событий на syslog-сервер») |
Заданному получателю и на сервер агентов | События отправляются получателю, заданному в манифесте |
Типы событий в MaxPatrol EDR
- Системные события — собираются модулями WinEventLog, ETW и «Сбор данных из файлов журналов» с конечных устройств.
- События, регистрируемые модулями — результаты работы модулей конфигурации, обнаружения и реагирования непосредственно на агенте.
Параметры кэша — максимальный размер и время хранения событий на агенте при потере связи с сервером. При восстановлении соединения накопленные события автоматически отправляются. События ИБ кэшируются всегда, независимо от настроек группы.
Ограничение скорости — максимальная скорость передачи данных в обоих направлениях (агент ↔ сервер агентов). Критически важный параметр для инфраструктур с узкими каналами связи.
Перемещение агентов между группами
Агента можно перенести из одной группы в другую в любой момент. При этом с устройства удаляются все модули, установленные через политики исходной группы, и автоматически устанавливаются модули из политик новой группы (с учётом совместимости с ОС и версией агента).
Работа с планировщиком задач
Планировщик задач (Система → Планировщик задач с агентами) позволяет автоматизировать рутинные операции с агентами без ручного вмешательства.
Доступные операции
Доступные операции
- Перемещение агентов в группу — в том числе полезно для автоматической авторизации новых агентов.
- Обновление агентов — массовое обновление до нужной версии или установка конкретной.
- Удаление агентов — например, очистка записей об устаревших устройствах, на которых агент уже не запущен.
Рисунок 3. Создание задачи
Настройка задачи
При создании задачи задаётся расписание запуска — каждая задача может выполняться неограниченное число раз.
Также указывается, для каких агентов применяется задача. Можно использовать предустановленные фильтры: «Неавторизованные», «Все агенты», «Из выбранных групп» и другие. Любой фильтр можно дополнить условиями на языке запросов PDQL для более точного отбора устройств.
Пример: автоматическое распределение по подсетям
PDQL-фильтр in_subnet позволяет отслеживать расположение агентов по подсетям и автоматически применять к ним нужные политики. Например:
Это избавляет от необходимости вручную переназначать политики при перемещении устройств по сети.
Настройка задачи
При создании задачи задаётся расписание запуска — каждая задача может выполняться неограниченное число раз.
Также указывается, для каких агентов применяется задача. Можно использовать предустановленные фильтры: «Неавторизованные», «Все агенты», «Из выбранных групп» и другие. Любой фильтр можно дополнить условиями на языке запросов PDQL для более точного отбора устройств.
Пример: автоматическое распределение по подсетям
PDQL-фильтр in_subnet позволяет отслеживать расположение агентов по подсетям и автоматически применять к ним нужные политики. Например:
- строгие политики с автоматическим реагированием — для агентов в критичных сегментах;
- облегчённые политики — для тестовых или некритичных сегментов.
Это избавляет от необходимости вручную переназначать политики при перемещении устройств по сети.
Рисунок 4. Пример PDQL-фильтра in_subnet
Политики и модули
Политика — инструмент управления набором модулей на конечных устройствах. Политика содержит перечень модулей с их параметрами. После назначения политики группе агентов все модули автоматически устанавливаются на устройствах этой группы.
Модуль — приложение, которое запускается локально на агенте и выполняет конкретную функцию: сбор данных, обнаружение угроз, реагирование или интеграцию. Поскольку модули работают на самом устройстве, агент остаётся полностью автономным: при потере связи с сервером он продолжает выполнять все назначенные функции.
Типы модулей
Напомним пять основных типов (подробное описание каждого — в разделе «Архитектура и компоненты»):
Помимо них существуют системные модули, обеспечивающие работу всех остальных.
Зависимости модулей
Ряд модулей зависит от других: им нужны данные или предварительные действия смежного модуля. Для выполнения зависимости необходимо:
При создании политики система автоматически выделяет необеспеченные зависимости. Детальный список доступен на вкладке «Зависимости» внутри политики и в карточке агента или группы.
Модуль — приложение, которое запускается локально на агенте и выполняет конкретную функцию: сбор данных, обнаружение угроз, реагирование или интеграцию. Поскольку модули работают на самом устройстве, агент остаётся полностью автономным: при потере связи с сервером он продолжает выполнять все назначенные функции.
Типы модулей
Напомним пять основных типов (подробное описание каждого — в разделе «Архитектура и компоненты»):
- модули доставки и установки;
- модули сбора;
- модули обнаружения;
- модули реагирования;
- модули интеграции.
Помимо них существуют системные модули, обеспечивающие работу всех остальных.
Зависимости модулей
Ряд модулей зависит от других: им нужны данные или предварительные действия смежного модуля. Для выполнения зависимости необходимо:
- добавить нужный модуль в ту же политику;
- или назначить группе ещё одну политику, в которой этот модуль уже есть.
При создании политики система автоматически выделяет необеспеченные зависимости. Детальный список доступен на вкладке «Зависимости» внутри политики и в карточке агента или группы.
Рисунок 5. Зависимости модулей в политике
Также отслеживать зависимости модулей агента можно в карточке агента или группы агентов.
Также отслеживать зависимости модулей агента можно в карточке агента или группы агентов.
Рисунок 6. Зависимости модулей в группе
Структура карточки модуля
Внутри каждого модуля могут присутствовать следующие блоки:
Структура карточки модуля
Внутри каждого модуля могут присутствовать следующие блоки:
- Основные параметры — настройка поведения модуля.
- События — события ИБ, которые регистрирует модуль в процессе работы. Для каждого события можно назначить автоматические действия через Мастер назначения действий.
- Действия — список операций, которые модуль может выполнить.
Рисунок 7. Карточка модуля
Шаблоны политик
В MaxPatrol EDR поставляется набор готовых шаблонов политик для быстрого старта. Шаблоны разделены по задачам и семействам ОС:
Создание собственных шаблонов
Шаблоны политик
В MaxPatrol EDR поставляется набор готовых шаблонов политик для быстрого старта. Шаблоны разделены по задачам и семействам ОС:
Тип шаблона | Назначение |
Сбор данных | В том числе специализированные под роли Windows-узлов (АРМ, сервер, контроллер домена) |
Обнаружение угроз | С преднастроенными исключениями в корреляторе |
Ручное реагирование | Модули реагирования без автозапуска |
Автоматическое реагирование | Модули с преднастроенными триггерами |
Интеграция | Подключение к MaxPatrol VM, PT Sandbox и другим системам |
Создание собственных шаблонов
- На базе любой настроенной политики можно создать пользовательский шаблон — для повторного использования на других серверах агентов или других инсталляциях MaxPatrol EDR. Для этого настройте политику, затем нажмите Создать шаблон.
Рисунок 8. Создание шаблона политики
В дальнейшем шаблон можно применять при создании новых политик или изменять существующие через кнопку Изменить.
В дальнейшем шаблон можно применять при создании новых политик или изменять существующие через кнопку Изменить.
Рисунок 9. Создание политики на основе пользовательского шаблона
Рисунок 10. Изменение шаблона политики
Просмотр всех шаблонов (встроенных и пользовательских) — на странице Шаблоны политик.
Просмотр всех шаблонов (встроенных и пользовательских) — на странице Шаблоны политик.
Рисунок 11. Список всех шаблонов политик
Рекомендации по работе с политиками
Используйте встроенные шаблоны как отправную точку, а не финальное решение — они показывают возможности продукта, но не учитывают особенности конкретной инфраструктуры.
Стремитесь к гранулярности: создавайте отдельные политики под конкретные задачи, а не одну политику «для всего»:
Такой подход позволяет гибко управлять комбинациями политик для разных групп и точечно перенастраивать нужные параметры без влияния на остальных.
При настройке политик ориентируйтесь на аппаратные ресурсы конечных устройств. Потребление агентом CPU и памяти зависит от состава установленных модулей, их параметров и интенсивности потока событий (EPS). Расчёты потребления приведены в документации.
Рекомендации по работе с политиками
Используйте встроенные шаблоны как отправную точку, а не финальное решение — они показывают возможности продукта, но не учитывают особенности конкретной инфраструктуры.
Стремитесь к гранулярности: создавайте отдельные политики под конкретные задачи, а не одну политику «для всего»:
- политики сбора событий с учётом роли узла и нужного уровня детализации;
- политики обнаружения с набором модулей, соответствующим критичности устройства;
- политики реагирования, отражающие разрешённые действия на конкретной группе;
- политики автоматического реагирования для устройств с высоким уровнем доверия к автоматике;
- политики интеграции — отдельно для MaxPatrol VM, PT Sandbox и других систем.
Такой подход позволяет гибко управлять комбинациями политик для разных групп и точечно перенастраивать нужные параметры без влияния на остальных.
При настройке политик ориентируйтесь на аппаратные ресурсы конечных устройств. Потребление агентом CPU и памяти зависит от состава установленных модулей, их параметров и интенсивности потока событий (EPS). Расчёты потребления приведены в документации.
Сценарии использования MaxPatrol EDR
Модульная архитектура продукта позволяет адаптировать его под любую инфраструктуру и внедрять поэтапно. Ниже — три базовых сценария, которые можно реализовывать как последовательно, так и в сочетании друг с другом.
Сценарий 1. Инвентаризация и сбор событий
Минимальный вариант внедрения — агент работает как инструмент сбора данных и инвентаризации активов.
Подходит, если основная цель — обогатить SIEM качественной телеметрией с конечных устройств или получить актуальную карту активов для MaxPatrol VM.
Преимущества:
Сценарий 2. Сбор событий и ручное реагирование
Расширенный вариант: к сбору телеметрии добавляется возможность реагировать на угрозы вручную — непосредственно с рабочего места аналитика.
Подходит, когда SOC-команда хочет сохранить контроль над каждым действием на хосте, не автоматизируя реагирование.
Преимущества:
Сценарий 3. Полноценный EDR: обнаружение и автоматическое реагирование
Максимальный сценарий — продукт работает в полную силу: поведенческий анализ, сигнатурное обнаружение, проверка IoC и автоматизированное реагирование без участия оператора.
Подходит для зрелых SOC-команд, которые доверяют настроенным правилам и хотят минимизировать время реакции на угрозы.
Преимущества:
Сценарий 1. Инвентаризация и сбор событий
Минимальный вариант внедрения — агент работает как инструмент сбора данных и инвентаризации активов.
Подходит, если основная цель — обогатить SIEM качественной телеметрией с конечных устройств или получить актуальную карту активов для MaxPatrol VM.
Преимущества:
- быстрое и простое внедрение;
- минимальная нагрузка на конечные устройства;
- возможность сэкономить на лицензии (достаточно MaxPatrol EDR Lite или Lite Plus).
Сценарий 2. Сбор событий и ручное реагирование
Расширенный вариант: к сбору телеметрии добавляется возможность реагировать на угрозы вручную — непосредственно с рабочего места аналитика.
Подходит, когда SOC-команда хочет сохранить контроль над каждым действием на хосте, не автоматизируя реагирование.
Преимущества:
- баланс между функциональностью и нагрузкой на инфраструктуру;
- аналитик может изолировать устройство, заблокировать процесс или собрать артефакты непосредственно из интерфейса SIEM;
- не требует тонкой настройки правил автоматики.
Сценарий 3. Полноценный EDR: обнаружение и автоматическое реагирование
Максимальный сценарий — продукт работает в полную силу: поведенческий анализ, сигнатурное обнаружение, проверка IoC и автоматизированное реагирование без участия оператора.
Подходит для зрелых SOC-команд, которые доверяют настроенным правилам и хотят минимизировать время реакции на угрозы.
Преимущества:
- угрозы обнаруживаются непосредственно на хосте — без необходимости передавать все данные в SIEM;
- комбинирование корреляций, YARA и IoC обеспечивает многоуровневую проверку;
- автоматическое реагирование сокращает время от обнаружения до локализации угрозы.
Заключение
Мы узнали, что группы служат базовой единицей управления: через них назначаются политики и параметры работы агентов, а политики определяют состав и конфигурацию модулей, которые автоматически разворачиваются на всех устройствах группы. Продукт поддерживает три сценария применения: от лёгкого сбора телеметрии до полноценного автоматизированного обнаружения и реагирования. В следующей статье дадим рекомендации по настройке модулей и работе с событиями MaxPatrol EDR.
Спасибо за прочтение! До встречи в следующих статьях курса!
Спасибо за прочтение! До встречи в следующих статьях курса!
Может быть интересно
