Аудит информационных процессов в операционных системах Windows

Министерство образования Российской Федерации Уфимский государственный авиационный технический университет

АУДИТ ИНФОРМАЦИОННЫХ ПРОЦЕССОВ

В ОПЕРАЦИОННЫХ СИСТЕМАХ WINDOWS 2000,XP

к лабораторной работе по курсам «Защита информационных процессов в компьютерных системах», «Методы и средства защиты компьютерной информации»

Составитель: В.Е.Кладов УДК 004.056.53

Аудит информационных процессов в операционных системах Windows 2000, XP. Методические указания к лабораторной работе по курсам «Зашита информационных процессов в компьютерных системах», «Методы и средства защиты компьютерной информации» / Уфимск. гос. авиац. техн. ун-т.; Cост. В.Е.Кладов. – Уфа, 2003. — 27 с.

Рассматривается организация аудита информационных процессов в операционных системах Windows 2000, XP. Предназначены для студентов специальности 075400 «Комплексная защита объектов информатизации», 220100 «Вычислительные машины, комплексы и системы», 220200 «Автоматизированные системы обработки информации и управления», 220300 «Системы автоматизированного проектирования» и направления 552800 «Информатика и вычислительная техника».

Библиогр.: 3 назв.

Рецензенты : Валеев С.С. Нугаев Р.Р

2 Теоретическая часть.

2.2. Определение необходимости записи аудита.

Аудит входа в систему (Audit loon events) .

Аудит событий входа в систему (Audit account logon events).

Аудит доступа к объектам.

Аудит использования привилегий.

Аудит управления учетными записями.

2.7.Аудит доступа к службе каталогов.

Аудит изменений политики.

Аудит системных событий.

2.10 Аудит отслеживания процессов.

2.11 Дополнительные программы и средства аудита.

2.11.1 Windows 2000 Events (w2000events.mdb) .

2.11.2. Windows 2000 error and Event Messanges Help .

2.11.3 Audit Policy (AuditPol).

2.11.4 Event Logging Utility (Logevent) .

2.11.5 Dump Event Log (Dumpel).

2.11.8 Crystal Reports Event Log Viewer .

2.11.9 Программа Intrust .

2.11.10 Enterprise Security Reporter.

3 Порядок выполнения работы .

4 Контрольные вопросы.

АУДИТ ИНФОРМАЦИОННЫХ ПРОЦЕССОВ

В ОПЕРАЦИОННЫХ СИСТЕМАХ WINDOWS 2000,XP

Целью работы является знакомство с организацией аудита информационных процессов в сетевых операционных системах Windows 2000, XP.

2 Теоретическая часть

2.1 Журналы событий

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

• системный журнал содержит информацию о событиях, относящихся к компонентам NT-XP, например, сообщения о сбое драйвера или службы при загрузке;

• журнал безопасности — события, связанные с безопасностью;

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

По умолчанию системный журнал и журнал приложений могут просматривать все пользователи, журнал безопасности — только администраторы. Пользователи с привилегией управления аудитом и журналом безопасности могут читать и очищать журнал безопасности (по умолчанию это только администраторы) (табл.1).

Журналы NTXP находятся в папке winnt_root\system32\ config в трех файлах (рис.2):

• AppEvent.еvt (журнал приложений);

• SecEvent.evt (журнал безопасности);

• SysEvent.evt (системный журнал).

Рис.2 При запуске их открывает и блокирует ОС, и даже на дисках с файло-

вой системой FAT получить доступ к файлам журналов, применяя стандартные средства, невозможно. Информация о событиях хранится на диске в бинарном виде. Журнал можно просмотреть в Windows 2000/XP с помощью программы просмотра событий из группы программ «Администрирование» (рис. 1).

В журнал для событий записывается следующая информация.

• источник, т.е. ПО, произведшее запись;

• имя пользователя, действия которого привели к возникновению

• имя компьютера, где произошло событие.

При нажатии левой клавиши мыши на определенном событии из журнала можно получить более детальную информацию о данном собы-

Рис.3 Командой « Сохранить файл журнала как» можно сохранить данные в

Рис.4 В свойствах журнала можно определить действия при заполнении

файла данного журнала (рис.4):

• затирать старые события при необходимости;

• затирать событие старше N дней, иначе новые события будут проигнорированы;

• не затирать события (очистка журнала вручную).

Для сортировки и фильтрации служит лист «Фильтр» свойств журнала (рис.5).

2.2. Определение необходимости записи аудита

Каждая запись в SACL обрабатывается так

• записи с типом не SystemAudit игнорируются;

• при отсутствии совпадений SID в записи с набором SID субъекта запись пропускается;

• маска требуемого доступа сравнивается с маской доступа в АСЕ, если ни один тип доступа, указанный в маске АСЕ, не требовался пользователем, запись пропускается, в противном случае проверяются биты SUCCESSFUL_ACCESS_ACE_FLAG и FAILED_AС CESS_ACE_FLAG;

• если пользователь получил доступ, а бит SUCCESSFUL_ACCESS ACE_FLAG не установлен, или пользователю доступ был запрещен,

а бит FAILED_ACCESS_ACE_FLAG не установлен, запись пропускается;

• если запись прошла все проверки, монитор безопасности генерирует событие о доступе к объекту, которое должно быть помещено в журнал аудита.

По умолчанию аудит безопасности не ведется. В Windows 2000, XP аудит включается администратором в оснастке «Локальные параметры безопасности» (рис.6).

Рис. 6 На контроллере домена правила аудита определяются для всех кон-

троллеров в этом домене. На рабочей станции и сервере не являющемся контроллером домена, правила аудита задаются индивидуально для каждого компьютера

Рассмотрим категории событий, регистрируемых системой безопасности.

2.3 Аудит входа в систему (Audit loon events)

Событие успешной регистрации пользователя в системе имеет номер (ID) 528. Событие с номером 538 означает завершение сеанса, начало которого зафиксировано событием 528 (рис.7).

Рис. 7 Событие номер 528 имеет несколько очень важных дополнительных

параметров. Имя пользователя и домен определяют вошедшего в систему пользователя или то, чья учетная запись была при этом задействована. Любому активному сеансу работы пользователя с системой присваивается уникальный код входа. Именно он будет записан в событии завершения сеанса, что позволяет определить общее время работы пользователя при анализе событий 528 и 538 с одинаковым кодом входа. В случае нескольких одновременных сессий одного пользователя (например, когда во-

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

Тип входа показывает, как пользователь вошел в систему:

• 2 — интерактивный вход с консоли, например, с помощью монитора и клавиатуры;

• 3 — сетевой вход , пользователь подключился по сети , к диску этого ПК или как-либо еще использует сетевой ресурс;

• 4- заданию на выполнение командного файла при использовании планировщика задач независимых компаний;

• 5 — фиксируется при запуске службы с указанием конкретной учетной записи пользователя;

• 7- разблокирование рабочей станции;

• 8 –сетевая регистрация незашифрованным паролем;

• 9 –ролевая (impersonated) регистрация.

В Windows NT событие 528 применялось для регистрации события любого типа. С Windows 2000 при подключении к диску на сервере, соединении с реестром сервера и выполнении других операций с использованием сетевой регистрации в журнал новое событие ID 540. Это позволяет отделить сетевую регистрацию от других типов регистрации.

В событиях 540 следует обратить внимание на поле Пользователь. Обычная пользовательская учетная запись свидетельствует, что пользователь зарегистрировался в системе через сеть; на эти события следует обратить внимание. Запись SYSTEM, указывающая, что одна системная служба устанавливает соединение с другой службой на той же машине. Имя компьютера с символом $ означает, что системная служба на удаленной машине устанавливает связь с системными службами на данном компьютере. Например, рабочая станция Windows 2000 Professional немедленно после запуска связывается с контроллером DC, чтобы получить информацию из AD и обратиться к другим доменным службам.

В поле «Домен» события 528, 540 указывается NetBios имя домена,

в котором расположена учетная запись пользователя. При регистрации с помощью локальной учетной записи в локальной базе SAM (диспетчер учетных записей), в имени «Домен» содержится имя NetBIOS компьютера. С помощью полей «Процесс входа» и «Пакет проверки» события ID 540 можно определить используемый протокол аутентификации Windows 2000 (NTLM или Kerberos).

При отметке Negotiate о регистрации NTLM в поле события «Рабочая станция» можно видеть имя NetBIOS клиентского компьютера. Если Windows 2000 использует механизм Kerberos, то это поле остается пустым.

Фиксируются также все неудачные попытки входа в систему. Событие 529 соответствует указанию неверного имени пользователя или паро-

Если учетная запись пользователя недоступна или заблокирована, то записывается событие с номером соответственно 531 или 539.

Событие номер 530 указывает, что пользователь пытался войти в систему в недозволенное ему время или день недели.

Если учетная запись пользователя просрочена или устарел пароль, то фиксируется соответственно событие 532 или 535.

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

Можно ограничить права пользователя на выполнение определенных типов входа в различные системы. Если пользователь, которому запрещен доступ к какому-то компьютеру по сети, все же пытается обратиться к его ресурсу или реестру, то он получит отказ, а в журнал безопасности запишется событие с номером 534. Такое же событие будет зафиксировано при попытке пользователя войти в систему с консоли, если это ему запрещено. При попытке запустить службу с использованием учетной записи пользователя, не имеющей права на запуск служб (права «Вход в качестве службы»), также будет зафиксировано событие номер 534. Кроме того, событие 534 запишется и при попытке запуска задания с исполнением командного файла от имени учетной записи без права «Вход в качестве пакетного задания».

При всех других отказах в аутентификации фиксируется событие с номером 537 — отказ по неизвестной причине. Тип входа фиксируется при всех попытках входа в систему, независимо от их результата.

События категории «Аудит входа в систему» регистрируются в локальном журнале безопасности рабочей станции.

2.4 Аудит событий входа в систему (Audit account logon events)

Появился с Windows 2000. Данная категория событий используется для отслеживания аутентификации пользователей на контроллерах доменов.

При использовании протокола аутентификации Kerberos Событие с ID 672 позволяет контролировать первичные подключения к домену при помощи процедуры получения билета TGT, а событие с ID 673 контролирует доступ к сетевым службам при помощи процедуры получения билета доступа к службе.

При вводе при аутентификации неправильного пароля контроллер домена записывает в журнал событие с ID 675 (ошибка предварительной аутентификации) с кодом ошибки 24. В сообщении указывается не только имя пользователя и имя домена, но и IP-адрес станции, с которой осуществлялась попытка несанкционированного доступа. Событие с ID 675 записывается еще и в том случае, если пользователь зарегистрировался на

Работа с событиями аудита Windows – сбор, анализ, реагирование

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.

Вход учетной записи

Аудит проверки учетных данных

Целесообразно контролировать на домен-контроллерах при использовании NTLM-аутентификации.

Аудит службы проверки подлинности Kerberos

Неуспешная аутентификация учетной записи на контроллере домена с использованием Kerberos-аутентификации.

Запрос билета Kerberos, при этом следует анализировать коды ответа сервера.

Данный тип аудита следует включать на контроллерах домена, при этом для детального изучения попыток подключения и получения IP-адреса подключающегося устройства на контроллере домена следует выполнить команду nltest /dbflag:2080ffff и проводить аудит текстового лог-файла %windir%\debug\​netlogon.log

Управление учетными записями

Аудит управления учетными записями компьютеров

Заведение устройства в домен Active Directory; может использоваться злоумышленниками, поскольку любой пользователь домена по умолчанию может завести в домен 10 устройств, на которых может быть установлено неконтролируемое компанией ПО, в том числе вредоносное.

Аудит управления группами безопасности

Добавление члена глобальной группы.

Добавление члена локальной группы.

Добавление члена универсальной группы.

Аудит управления учетными записями пользователей

Создание учетной записи.

Отключение учетной записи.

Блокировка учетной записи.

Аудит создания процессов

При создании процесса.

При завершении процесса.

Чтобы для командного интерпретатора велась запись введенных команд, следует включить политику «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Система — Аудит создания процессов -> Включать командную строку в события создания процессов».

Чтобы велась запись выполняемых PowerShell-команд и загруженных PowerShell-модулей, следует включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Компоненты Windows — Windows PowerShell» политики «Включить ведение журнала модулей» (в настройках политики указать все модули символом «*») и «Включить регистрацию блоков сценариев PowerShell» (в настройках политики отметить check-box «Регистрация начала или остановки вызова блоков сценариев»). Работа PowerShell-скриптов регистрируется с EventID=4104,4105,4106 в журнале Microsoft-Windows-PowerShell/Operational, а загрузка PowerShell-модулей регистрируется с EventID=800 в журнале Windows PowerShell.

Аудит выхода из системы

Для неинтерактивных сессий.

Для интерактивных сессий и RDP-подключений.

При этом следует обращать внимание на код Logon Type, который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.).

Аудит входа в систему

При успешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM и Kerberos-аутентификации.

При неуспешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM аутентификации; при Kerberos-аутентификации на контроллере домена создается EventID=4771.

При попытке входа с явным указанием учетных данных, например, при выполнении команды runas, а также при работе «хакерской» утилиты Mimikatz.

При этом следует обращать внимание на код входа (Logon Type), который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). Целесообразно также обращать внимание на код ошибки (Status/SubStatus), который также сохраняется в событии аудита и характеризует причину неуспешного входа — несуществующее имя учетной записи, недействительный пароль, попытка входа с заблокированной учетной записью и т.д.

Аудит других событий входа и выхода

RDP-подключение было установлено.

RDP-подключение было разорвано.

Аудит специального входа

При входе с административными полномочиями.

Доступ к объектам

Аудит сведений об общем файловом ресурсе

При доступе к системных сетевым ресурсам, таким как \\C$\ .

Данное событие будет создаваться при работе ransomware, нацеленного на горизонтальное перемещение по сети.

Аудит других событий доступа к объектам

При создании задания в «Планировщике задач», что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе.

Аудит изменения политики аудита

Изменение политики аудита.

Изменение настройки CrashOnAuditFail.

Изменить реакцию ОС на невозможность вести журнал аудита безопасности (настройка CrashOnAuditFail) можно в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» в политике «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности».

Аудит расширения системы безопасности

При появлении в системе новых пакетов аутентификации, что не должно происходить несанкционированно.

При создании нового сервиса, что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе.

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY\NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN\Event Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера. » (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address. ) и указать адрес сервера-коллектора в следующем формате:

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe – файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.