Три слона, на которых держится логирование в Windows

Анастасия Кузнецова, Security Vision

Данное исследование было проведено в рамках проработки агентской истории для целой группы продуктов.

Продолжаем наш цикл статей о типах и методах работы сборщиков данных с конечных точек, или, как принято их называть – агентов. В первой статье мы познакомились с этой сущностью и изучили основные нюансы сбора данных с их помощью. Так как мы в рамках разработки своих продуктов занимаемся и лог-менеджментом, и сбором событий, то хочется поделиться продолжением нашей обширной аналитики в quickstart формате. Поэтому в этом выпуске подробнее разберем функционал и используемые инструменты источников на ОС Windows.

Начнем с того, что самому агенту по большей части все равно, посредством какой технологии производится сбор данных. Однако, при внедрении агентов в собственную инфраструктуру в рамках политики безопасности всегда есть какие-либо ограничения на использование тех или иных инструментов, портов и прочего. В связи с этим и рассмотрим возможные источники передачи данных для агентов.

Если мы хотим собирать данные с конечных точек на ОС Windows, то существует три основных инструмента. Первым является подсистема аудита Windows, хранящая события в формате EventLog. Это средство журналирования событий Windows, в котором регистрируются сообщения операционной системы. События делятся на несколько групп – журналов:

К тому же, некоторые приложения пишут свои собственные события в отдельную папку, к примеру:

В этой папке могут оказаться логи как процессора, так и ПО (звуковых драйверов или того же Kaspersky).

Также существуют отдельные журналы для:

• DNS Manager

• Failover Cluster Manager

• IIS Access

• Task Scheduler History

• Windows Component Service

События системных журналов в формате EventLog уже имеют некоторую начальную нормализацию и содержат следующие поля:

• Дата в формате: месяц, день, время и год.

• Категория события как целое число

• Уровень события

• ID безопасности Windows

• Источник Windows.

• Ключевые слова журнала событий Windows.

• Идентификатор событий Windows.

• Текст сообщения

Для журналов событий существует возможность изменять права доступа на чтение, запись и очистку. В этом смысле особняком стоит журнал безопасности (Security) — право записи в него зарезервировано исключительно для локального органа безопасности Windows (LSASS). Также есть возможность добавлять типы событий в журнал Безопасности и назначать источник из зарегистрированных приложений.

Для первичной аналитики, а тем более расследования инцидентов, информации только с EventLog не всегда бывает достаточно. В связи с этим активно используется другая утилита с расширенными функциями аудита событий – Sysmon, входящий в пакет Sysinternals. По сути, она является системной службой Windows, которая отдает подробные данные о приходящих событиях, сетевых подключениях и драйверах, изменениях файлов и многом другом. Я нашла вот такую карту интересных данных, которые можно собирать с помощью Sysmon (для подробностей рекомендую заглянуть сюда.

Для обеспечения дополнительного уровня безопасности Sysmon обычно устанавливается вместе с другими решениями для защиты конечных точек, такими как традиционный антивирус, система управления событиями (SIEM) или средство обнаружения и реагирования на конечных точках (EDR). Драйвер этой службы позволяет осуществлять сбор сразу при включении устройства, т.е. до запуска основных компонентов компьютера.

Вдобавок, данный инструмент довольно хорошо описан и популярен, а значит, на просторах интернета существует множество готовых конфигураций под различные требования аудита событий.

Единственный существенный недостаток Sysmon — слабая совместимость с классом ОС Linux. Для таких ОС регистрируется только некоторая часть событий, регистрируемых в Windows системах (Event ID 1, 3, 4, 5, 9, 11, 16, 23).

Искать логи в интерфейсе «Просмотра событий» следует в журнале Applications and Services Logs\Microsoft\Windows\Sysmon. Вот пример события:

И наконец, замыкает тройку первостепенных технологий сбора событий средство Event Tracing for Windows (ETW) – трассировка событий Windows. Технология предоставляется в самой ОС по умолчанию и осуществляется на уровне ядра. ETW фиксирует журналы событий, создаваемых драйверами ядра и пользовательскими приложениями. Тот же Sysmon формирует часть своих событий на его основе. Для понимания сути ETW нам понадобится использовать несколько понятий:

   ·   Провайдеры (providers, поставщики событий) — это приложения (например, DLL), у которых есть функции регистрации событий. Именно провайдер отслеживает состояния приложений (или системы) и отправляет события в сессию.

   ·   Сессии (sessions, сеанс трассировки, логгер) — сущности, которые собирают события от провайдеров и передают их потребителям. Одна сессия может потреблять события от одного или нескольких провайдеров. Также сессии сортируют события между собой, чтобы передавать их нужным потребителям.

   ·   Контроллеры (controllers) — это приложения, которые управляют сессиями. Могут создавать или удалять сессии, а также изменять их параметры.

   ·   Потребители событий (consumers) — приложения, которые могут получать и как‑то обрабатывать события от одной или нескольких сессий, а также из файлов.

Провайдеры формируют и передают события о состояниях, происходящих внутри процессов или ядра, а потребители используют эти события для собственных целей (например, для анализа производительности). Схему процесса передачи данных вендор представляет следующим образом:

ETW в своей базовой конфигурации является простым механизмом межпроцессного взаимодействия и функционирует только локально, и в подавляющем большинстве исследований используется как «оборонительный» инструмент.

События от этого источника можно обнаружить в дереве Applications and Services Logs и Windows Logs\Security.

Если вы хотите углубиться в логику работы и базовое администрирование ETW, рекомендую изучить следующую статью, где понятным языком описаны внутренние процессы службы трассировки.

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

Так что предлагаю некоторые критерии оценки качества передаваемых данных:

• События должны быть достоверными, то есть нужно быть уверенными, что записанные события действительно случились и что атрибуты событий являются верными;

• Лог событий должен быть завершенным, то есть предоставлять полную картину действий;

• У любых записываемых событий должна быть четко определенная семантика, то есть разнотипные события должны различаться.

Данная статья носит исключительно ознакомительный характер и ни в коем случае не говорит о том, какие именно средства сбора событий должны использовать именно вы. Данная статья скорее будет полезна тем, кто только погружается в аудит событий конечных устройств Windows – друзья, теперь вы знаете, куда копать дальше. А в следующей статье расскажем о журналировании в ОС класса Linux.