Журнал windows безопасность очень много аудита успеха

( 1 оценка, среднее 3 из 5 )

Проблемы в системе журналирования событий безопасности ОС Windows

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

Выявленные проблемы проверялись на Windows 7 Максимальная (русская версия), Windows 7 Professional (английская версия), Windows 10 Pro (русская версия), Windows Server 2019 Datacenter (русская версия). Все операционные системы были полностью обновлены.

Проблема № 1. Неудачная система управления параметрами аудита

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

Объяснение

Чтобы разобраться в причине подобного поведения, надо залезть «под капот» операционной системы. Начнем с того, что разберемся с базовыми и расширенными политиками аудита.

До Windows Vista были только одни политики аудита, которые сейчас принято называть базовыми. Проблема была в том, что гранулярность управления аудитом в то время была очень низкой. Так, если требовалось отследить доступ к файлам, то включали категорию базовой политики «Аудит доступа к объектам». В результате чего помимо файловых операций в журнал безопасности сыпалась еще куча других «шумовых» событий. Это сильно усложняло обработку журналов и нервировало пользователей.

Microsoft услышала эту «боль» и решила помочь. Проблема в том, что Windows строится по концепции обратной совместимости, и внесение изменений в действующий механизм управления аудитом эту совместимость бы убило. Поэтому вендор пошел другим путем. Он создал новый инструмент и назвал его расширенными политиками аудита.

Суть инструмента заключается в том, что из категорий базовых политик аудита сделали категории расширенных политик, а те, в свою очередь, разделили на подкатегории, которые можно отдельно включать и отключать. Теперь при необходимости отслеживания доступа к файлам в расширенных политиках аудита необходимо активировать только подкатегорию «Файловая система», входящую в категорию «Доступ к объектам». При этом «шумовые» события, связанные с доступом к реестру или фильтрацией сетевого трафика, в журнал безопасности попадать не будут.

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

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

Наименование базовых политик аудита	Наименование расширенной политики аудита
Аудит доступа к службе каталогов	Доступ к службе каталогов (DS)
Аудит доступа к объектам	Доступ к объектам
Аудит использования привилегий	Использование прав
Аудит входа в систему	Вход/выход
Аудит событий входа в систему	Вход учетной записи
Аудит изменения политики	Изменение политики
Аудит системных событий	Система
Аудит управления учетными записями	Управление учетными записями
Аудит отслеживания процессов	Подробное отслеживание

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

Теперь настало время разобраться с тем, где хранятся настройки аудита. Для начала введем ряд понятий:

Наименование средства	Отображаемые политики аудита	Сохраняемые политики аудита
«Базовые политики аудита» оснастки «Локальные политики безопасности»	Эффективные политики аудита	Эффективные политики аудита, сохраненные политики аудита
«Расширенные политики аудита» оснастки «Локальные политики безопасности»	Файл %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.csv
Утилита auditpol	Сохраненные параметры аудита	Эффективные параметры аудита, сохраненные параметры аудита

Поясним таблицу на примерах.

Отдельного комментария требует порядок отображения параметров аудита в «Базовых политиках аудита» оснастки «Локальные политики безопасности». Категория базовой политики аудита отображается как установленная, если установлены все подкатегории соответствующей ей расширенной политики аудита. Если хотя бы одна из них не установлена, то политика будет отображаться как не установленная.

Администратор с помощью команды auditpol /set /category:* установил все подкатегории аудита в режим «Аудит успехов». При этом если зайти в «Базовые политики аудита» оснастки «Локальные политики безопасности», то напротив каждой категории будет установлено «Аудит успеха».

В «Базовых политиках аудита» оснастки «Локальные политики безопасности» эти сведения об аудите не отображаются, так как во всех категориях не определена одна или более подкатегорий. В «Расширенных политиках аудита» оснастки «Локальные политики безопасности» эти сведения не отображаются, так как оснастка работает только c параметрами аудита, хранящимися в файле %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.csv.

В чем суть проблемы?

По началу может показаться, что все это и не проблема вовсе, но это не так. То, что все инструменты показывают параметры аудита по разному, создает возможность к злонамеренному манипулированию политиками и, как следствие, результатами аудита.

Рассмотрим вероятный сценарий

Пусть в корпоративной сети работает технологическая рабочая станция на базе Windows 7.

Машина не включена в домен и выполняет функции робота, ежедневно отправляющего отчетность в контролирующие органы. Злоумышленники тем или иным образом получили на ней удаленный доступ с правами администратора. При этом основная цель злоумышлеников — шпионаж, а задача — оставаться в системе незамеченными. Злоумышленники решили скрытно, чтоб в журнале безопасности не было событий с кодом 4719 «Аудит изменения политики», отключить аудит доступа к файлам, но при этом чтобы все инструменты администрирования говорили, что аудит включен. Для достижения поставленной задачи они выполнили следующие действия:

Проблема № 2. Неудачная реализация журналирования операций удаления файлов, каталогов и ключей реестра

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

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

Событие 1. Код 4663 «Выполнена попытка получения доступа к объекту». Параметры события:
«ObjectType» = File.
«ObjectName» = имя удаляемого файла или каталога.
«HandleId» = дескриптор удаляемого файла.
«AcessMask» = 0x10000 (Данный код соответствует операции DELETE. С расшифровкой всех кодов операций можно ознакомиться на сайте Microsoft).

Событие 2. Код 4660 «Объект удален».
Параметры события:

«HandleId» = «HandleId события 1»
«SystemEventRecordID» = «SystemEventRecordID из события 1» + 1.

С удалением ключа (key) реестра всё то же самое, только в первом событии с кодом 4663 параметр «ObjectType» = Key.

Отметим, что удаление значений (values) в реестре описывается другим событием (код 4657) и подобных проблем не вызывает.

Особенности удаления файлов в Windows 10 и Server 2019

В Windows 10 / Server 2019 процедура удаления файла описывается двумя способами.

В чем суть проблемы?

Проблема заключается в том, что узнать кто удалил файл или каталог, становится нетривиальной задачей. Вместо банального поиска соответствующего события по журналу безопасности необходимо анализировать последовательности событий, что вручную делать довольно трудоемко. На хабре даже по этому поводу была статья: «Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell».

Проблема № 3 (критическая). Неудачная реализация журналирования операции переименования файлов, каталогов и ключей реестра

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

Эта проблема состоит из двух подпроблем:

В чем суть проблемы?

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

Проблема № 4 (критическая). Невозможно отследить создание каталога и ключа реестра

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

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

В чем суть проблемы?

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

Проблема № 5 (критическая). Сбойные параметры аудита в русских версиях Windows

Наличие проблемы подтверждено на русских редакциях Windows 7/10/Server 2019.

Описание проблемы

В русских версиях Windows есть ошибка, приводящая систему управления аудитом безопасности в нерабочее состояние.

Симптомы

Причины

Проблема возникает, если администратор активировал хотя бы одну из «сбойных» подкатегорий расширенных политик аудита. К подобным сбойным категориям, в частности, относятся:

Рекомендации по решению проблемы

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

Если проблема произошла, то необходимо:

В чем суть проблемы?

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

Проблема № 6 (критическая). Будь проклят «Новый текстовый документ.txt. а также Новый точечный рисунок.bmp»

Наличие проблемы подтверждено на Windows 7. Проблема отсутствует в Windows 10/Server 2019.

Описание проблемы

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

Из командной строки выполним команду: echo > «c:testНовый текстовый документ.txt»
Наблюдаем:

По факту создания файла в журнале безопасности появилось событие с кодом 4663, содержащее в поле «ObjectName» имя создаваемого файла, в поле «AccessMask» значение 0x2 («Запись данных или добавление файла»).

Для выполнения следующих экспериментов очистим папку и журнал событий.

В журнале событий данное действие никак не отразилось. Также никаких записей не будет, если с помощью того же контекстного меню создать «Точечный рисунок».

Как и в случае с созданием файла через командную строку в журнале появилось событие с кодом 4663 и соответствующим наполнением.

В чем суть проблемы?

Конечно создание текстовых документов или картинок особого вреда не представляет. Однако, если «Проводник» умеет обходить журналирование файловых операций, то это смогут сделать и вредоносы.

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

Заключение

Приведенный перечень проблем не исчерпывающий. В процессе работы удалось споткнуться о еще довольно большое количество различных мелких недоработок, к которым можно отнести использование локализованных констант в качестве значений параметров ряда событий, что заставляет писать свои анализирующие скрипты под каждую локализацию операционной системы, нелогичное разделение кодов событий на близкие по смыслу операции, например, удаление ключа реестра — это последовательность событий 4663 и 4660, а удаление значения в реестре — 4657, ну и еще по мелочи…

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

MAKE WINDOWS SECURITY EVENT LOGGING GREAT AGAIN!

Источник

Кто пытался войти в систему Windows

Это небольшая статья призвана показать пользователям способ, которым он узнает, кто пытался войти в систему без его ведома. Если компьютер находится в офисе и к нему имеют доступ не один человек, тогда способ может пригодиться. Советую ознакомиться со статьей – кто пытался войти через вашу учетную запись. Там говориться об учетной записи Microsoft, в которую могут войти любые злоумышленники.

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

Как использовать «Аудит входа в систему»

Данная функция доступна только в PRO версии Windows, где есть функция локальных групповых политик, в домашней или корпоративной её нет. Но в ниже есть другие варианты для вашей версии. Итак, откройте окно «Выполнить» и впишем команду:

Так мы запустим утилиту групповых политик. С левой стороны окошка открываем вкладки «Конфигурация компьютера», далее «Конфигурация Windows», «Параметры безопасности», «Локальные политики» и «Политика аудита». Нажмите на этот раздел, чтобы правее от окна появились нужные опции.

Теперь выбираем пункт «Аудит событий входа в систему» (Нажимаем на него правой кнопкой мышки дважды). Появится окно свойств, где выделяем галкой пункт «Успех». Таким образом, появится возможность отслеживать все входы в Windows. Отметив галкой «Отказ», будут отслеживаться неудачные входы в Windows.

Смотрим, кто пытался войти в систему

Активировав функцию, можно заново войти в систему. Давайте проверим, кто же входил в неё. Для этого дела нам понадобиться утилита «Просмотр событий». В поиске введите эти два слова.

В утилите перейдите в раздел «Журналы Windows» и подраздел «Безопасность». Справа находим ключевое событие «Аудит успеха», также смотрите по номеру события, он должен быть «4624».

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

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

В Windows 10 с помощью реестра

Если у вас не профессиональная редакция Windows, то воспользуемся реактором реестра. Снова откроем окошко «Выполнить» при помощи комбинации «Win+R» и запишем команду:

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

Выбрав последний раздел, в правой части окошка создаем параметр DWORD 32 бит. Дадим ему название DisplayLastLogonInfo. Нажимаем по нему два раза и ставим в качестве значения единицу.

Закрываем окна и перезагружаем ПК. После загрузки системы на экране появится окно с успешным входом. Там будет время, имя пользователя и дата.

Надеюсь этот небольшой материал поможет вам узнать, кто входил в систему при вашем отсутствии.

Источник

Управление журналом аудита и безопасности

Область применения

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

Справочники

Этот параметр политики определяет, какие пользователи могут указывать параметры аудита доступа к объекту для отдельных ресурсов, таких как файлы, объекты Active Directory и ключи реестра. Эти объекты указывают свои списки управления доступом к системе (SACL). Пользователь, которому назначено это право пользователя, также может просматривать и очищать журнал безопасности в viewer событий. Дополнительные сведения о политике аудита доступа к объекту см. в этой информации.

Возможные значения

Рекомендации

Location

Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment

Значения по умолчанию

По умолчанию этот параметр — администраторы на контроллерах домена и на автономных серверах.

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

Тип сервера или объект групповой политики	Значение по умолчанию
Default Domain Policy	Не определено
Политика контроллера домена по умолчанию	Администраторы
Параметры по умолчанию для автономного сервера	Администраторы
Действующие параметры по умолчанию для контроллера домена	Администраторы
Действующие параметры по умолчанию для рядового сервера	Администраторы
Действующие параметры по умолчанию для клиентского компьютера	Администраторы

Управление политикой

В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой.

Для активации этого параметра политики не требуется перезагрузка компьютера.

Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.

Аудит доступа к объекту не выполняется, если вы не включаете их с помощью редактора локальной групповой политики, консоли управления групповой политикой (GPMC) или средства командной строки Auditpol.

Дополнительные сведения о политике аудита доступа к объекту см. в этой информации.

Групповая политика

Параметры применяются в следующем порядке с помощью объекта групповой политики (GPO), который перезаписывал параметры на локальном компьютере при следующем обновлении групповой политики:

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

Вопросы безопасности

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

Уязвимость

Любой пользователь с правом управления аудитом и журналом безопасности может очистить журнал Безопасности, чтобы удалить важные доказательства несанкционированной деятельности.

Противодействие

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

Возможное влияние

Ограничение права пользователя журнала аудита и безопасности на локализованную группу администраторов — это конфигурация по умолчанию.

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

Источник

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

Журнал аудита определяет, генерирует ли операционная система события аудита при прекращении сеансов логотипа.

Эти события происходят на компьютере, к нему был доступ. Для интерактивного логотипа эти события создаются на компьютере, на который был внесен вход.

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

События Logon имеют важное значение для понимания активности пользователей и обнаружения потенциальных атак. События logoff не являются на 100 процентов надежными. Например, компьютер можно отключить без надлежащего входа и отключения; В этом случае событие входа не создается.

Объем событий: High.

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

Тип компьютера	Общий успех	Общий сбой	Более сильный успех	Более сильный сбой	Комментарии
Контроллер домена	Нет	Нет	Да	Нет	Эта подкатегория обычно создает огромное количество»4634(S): учетная запись была отключена». события, которые, как правило, имеют мало релевантности для безопасности. Важнее проверять события Logon с помощью подкатегории Audit Logon, а не событий Logoff. Включите аудит успешности, если вы хотите отслеживать, например, как долго сеанс был активен (в связи с событиями Audit Logon) и когда пользователь входил в систему. В этой подкатегории нет событий сбоя, поэтому нет рекомендации включить аудит отказа для этой подкатегории.
Сервер участника	Нет	Нет	Да	Нет	Эта подкатегория обычно создает огромное количество»4634(S): учетная запись была отключена». события, которые, как правило, имеют мало релевантности для безопасности. Важнее проверять события Logon с помощью подкатегории Audit Logon, а не событий Logoff. Включите аудит успешности, если вы хотите отслеживать, например, как долго сеанс был активен (в связи с событиями Audit Logon) и когда пользователь входил в систему. В этой подкатегории нет событий сбоя, поэтому нет рекомендации включить аудит отказа для этой подкатегории.
Workstation	Нет	Нет	Да	Нет	Эта подкатегория обычно создает огромное количество»4634(S): учетная запись была отключена». события, которые, как правило, имеют мало релевантности для безопасности. Важнее проверять события Logon с помощью подкатегории Audit Logon, а не событий Logoff. Включите аудит успешности, если вы хотите отслеживать, например, как долго сеанс был активен (в связи с событиями Audit Logon) и когда пользователь входил в систему. В этой подкатегории нет событий сбоя, поэтому нет рекомендации включить аудит отказа для этой подкатегории.

Список событий:

4634(S): учетная запись была отключена.

4647(S). Инициированный пользователем журнал.

Источник

Заметка о том, как провести аудит событий безопасности в операционной системе. Изучив эту заметку, вы ознакомитесь с подсистемой безопасности на примере Windows 10. После чего вы сможете самостоятельно проводить аудит событий безопасности операционных систем Windows.

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

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

Для запуска введите его название в строке поиска.

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

События входа и выхода

Например, в категории «аудит входа в систему» можно включить фиксацию успешных или неудачных попыток входа в систему.

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

Проверим, как это работает.  Я включу оба типа событий.

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

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

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

Для просмотра событий нужно открыть приложение просмотр событий.

Затем выбрать пункт меню журналы Windows –> Безопасность. В журнале будут отображены неудачные и удачные попытки входа в систему.

Кликнув на событие, вы можете просмотреть его свойства и подробности.

Существуют следующие типы входов операционную систему Windows.

Тип	Название	Описание
0	Системный (System)	Используется только учетной записью System, например при запуске системы.
2	Интерактивный (Interactive)	Локальный вход пользователя на компьютер.
3	Сетевой (Network)	Пользователь вошёл на данный компьютер через сеть.
4	Пакетный (Batch)	Пакетный тип входа используется пакетными серверами
5	Служба (Service)	Служба запущена Service Control Manager.
7	Разблокирование (Unlock)	Эта рабочая станция разблокирована
8	Сетевой ввод пароля (NetworkCleartext)	Пользователь вошёл на данный компьютер через сеть. Пароль пользователя передан в нехэшированной форме.
9	Новые полномочия (NewCredentials)	Посетитель клонировал свой текущий маркер и указал новые учётные записи для исходящих соединений
10	Удаленный интерактив (RemoteInteractive)	Пользователь выполнил удалённый вход на этот компьютер, используя службу терминалов или удаленный рабочий стол.
11	Кешированный интерактив (CachedInteractive)	Пользователь вошёл на этот компьютер с сетевыми учётными данными, которые хранились локально на компьютере.
12	Кешированный удаленный интерактив (CachedRemoteInteractive)	Метод используется для внутреннего аудита, аналогичен типу 11.

События администрирования

Вернемся к приложению локальная политика безопасности. Рассмотрим аудит управления учетными записями.

Данный аудит фиксирует события, которые связаны с управлением учетными записями. Фиксируются изменения в учетных записях. Если вы добавите новую учетную запись пользователя, или удалите существующую, то в журнале будет запись о том кто (имя учетной записи) когда и какое действие с учетной записью (создал, удалил, изменил) произвел.

Для примера я включил оба типа событий.

Затем я изменил тип учетной записи – сделал пользователя администратором.

В журнале безопасности появилась соответствующая запись.

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

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

Данный параметр фиксирует события связанные с изменением политик аудита. Разберемся на примере. Я включил оба типа событий.

После чего я добавил пользователя Local use в свойства прав архивация файлов и каталогов.

Теперь в журнале безопасности мы видим соответствующую запись об изменении прав пользователя.

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

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

Аудит использования привилегий фиксирует события связанные с применением пользователем назначенных ему привилегий.

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

Измените системное время.

В журнале безопасности вы увидите соответствующую запись о том, что системное время изменено.

Аудит событий операционной системы

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

Я включу аудит событий с типом успех. Затем очищу журнал аудита событий.

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

Аудит доступа пользователя к объектам

Этот аудит фиксирует события, которые связаны с доступом к файлам, папкам, реестру, оборудованию и так далее. При этом можно настроить аудит на различные типы доступа к папкам и файлам, например чтение, изменение, печать.

Я включу аудит двух типов событий.

Этот вид аудита в операционной системе Windows доступен только для файловой системы NTFS. При этом аудит доступен, если включить его в самом объекте.

Для примера я создам текстовый фал. Для настройки нужно перейти в его свойства -> безопасность -> дополнительно -> аудит. Далее следует добавить субъект и разрешения.

Я установил тип успех на чтение и выполнение этого файла.

После применения аудита я открыл и прочитал файл. Об этом появилась соответствующая запись в журнале безопасности.

Управление журналом аудита

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

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

При необходимости администратор может настроить вид журнала безопасности для определенного пользователя. Делается это с помощью меню фильтр текущего журнала.

На этом короткое руководство по аудиту событий безопасности в операционной системе Windows закончено.

Если у вас возникли вопросы – задавайте их в комментариях к данной заметке.

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

Получить доступ к этим записям можно через встроенное приложение Просмотр событий (Event Viewer). Есть несколько вариантов запуска данного приложения:

• через меню Пуск – Средства администрирования Windows – >Просмотр событий (Start – Windows Administrative Tools – Event Viewer);
• в командной строке или в окне Выполнить набрать eventvwr.msc:

В Диспетчере серверов в разделе Средства выбрать Просмотр событий (Server Manager – Tools – Event Viewer):

Описание интерфейса программы

Окно программы состоит из следующих компонентов:

• Панель навигации позволяет выбрать конкретный журнал, записи которого необходимо просмотреть;
• Список событий, содержащийся в выбранном журнале. В колонках выведена базовая информация о событии. Их можно отсортировать по датам, типам, категориям событий и т.д.;
• Детальная информация о выбранном во второй панели событии. Также детальную информацию можно открыть в отдельном окне, если кликнуть по нужному событию два раза;
• Панель быстрых действий, которые можно совершить с данным журналом или событием. Действия также доступны в контекстном меню (клик правой кнопкой мыши по журналу или событию).

Для удобства просмотра и управления системные журналы разбиты по категориям:

• Приложения (Application) – как и гласит название, содержит события и ошибки приложений;
• Безопасность (Security) – если в операционной системе включена и настроена функция аудита, журнал будет содержать записи, связанные с отслеживанием соответствующих событий (например, авторизация пользователя или попытки неудачного входа в операционную систему);
• Система (System) – здесь регистрируются события операционной системы и системных сервисов;
• Установка (Setup) – события, связанные с инсталляцией обновлений Windows, дополнительных приложений.

В разделе Журналы приложений и служб (Applications and Services Logs) можно найти более детальную информацию о событиях отдельных служб и приложений, зарегистрированных в операционной системе, что бывает полезно при диагностике проблем в работе отдельных сервисов.

Сами события также разделяются на типы:

• Сведения (Information) — информируют о штатной работе приложений.
• Предупреждение (Warning) — событие, свидетельствующее о возможных проблемах в будущем (например, заканчивается свободное место на диске – приложения могут продолжать работу в штатном режиме, но когда место закончится совсем, работа будет невозможна).
• Ошибка (Error) — проблема, ведущая к деградации приложения или службы, потерям данных.
• Критическое (Critical) — значительная проблема, ведущая к неработоспособности приложения или службы.
• Аудит успеха (Success audit) — событие журнала Безопасность (Security), обозначающее успешно осуществленное действие, для которого включено отслеживание (например, успешный вход в систему).
• Аудит отказа (Failure audit) — событие журнала Безопасность (Security) обозначающее безуспешную попытку осуществить действие, для которого включено отслеживание (например, ошибка входа в систему).

Работа с журналами

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

Правый клик по журналу – Фильтр текущего журнала… (>Filter Current Log…), либо выбрать данную функцию в панели быстрых действий. Открывшееся окно позволяет настроить фильтр и отобразить только те события, которые необходимы в данный момент:

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

Когда необходимость в фильтрации событий отпадет, ее можно отключить действием Очистить фильтр (Clear Filter):

Приложение Просмотр событий (Event Viewer) позволяет также настроить дополнительные свойства журналов. Доступ к настройкам можно получить через панель быстрых действий, либо через контекстное меню журнала – правый клик по журналу – Свойства (Properties):

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

В нижней части окна можно выбрать вариант действия при достижении журналом максимального значения:

• Переписывать события при необходимости (Overwrite events as needed) – новое событие будет записываться поверх самого старого события в журнале, таким образом будут доступны события только за определенный диапазон времени.
• Архивировать журнал при заполнении (Overwrite the log when full) – заполненный журнал будет сохранен, последующие события будут записываться в новый файл журнала. При необходимости доступа к старым событиям, архивный файл можно будет открыть в приложении Просмотр событий (Event Viewer).
• Не переписывать события (Do not overwrite events) – при заполнении журнала выдается системное сообщение о необходимости очистить журнал, старые события не перезаписываются.

Аverage rating : 5

Оценок: 1

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

700
300

ООО «ИТГЛОБАЛКОМ ЛАБС»

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

700
300

ООО «ИТГЛОБАЛКОМ ЛАБС»

700
300

В статье рассмотрим то, как мы можем проводить аудит безопасности системы Windows. Узнаем как настроить и смотреть логи связанные с аудитом.

Привилегии связанные с аудитом

С аудитом доступа связаны две привилегии:

• SeSecurityPrivilege — необходима для управления журналом событий безопасности и для просмотра или настройки SACL.
• SeAuditPrivilege — позволяет процессам, вызывать системные службы аудита для успешного генерирования записей аудита.

Настройка политики аудита

Настройка политики аудита осуществляется из оснастки “Локальная политика безопасности” (secpol.msc).

Схема работы аудита

LSASS отправляет сообщения SRM, чтобы проинформировать его о политике аудита в ходе инициализации системы, а потом при изменениях политики. В свою очередь LSASS получает события аудита от SRM, добавляет дополнительную информацию и отправляет их регистратору событий (Event Logger).

Записи аудита передаются от SRM к подсистеме безопасности LSASS одним из двух способов:

• если запись аудита невелика (меньше чем максимальный размер сообщения ALPC), она отправляется как ALPC-сообщение;
• ну а если запись аудита имеет большой размер, SRM использует общую память, чтобы сообщение было доступно LSASS, и просто передает указатель в ALPC-сообщении.

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

Аудит доступа к объекту по умолчанию выключен, как и другие политики аудита. Чтобы понаблюдать за тем, как работает аудит доступа к объекту, выполните следующие действия. В проводнике перейдите к файлу, к которому у вас есть доступ и откройте свойства этого файла, затем перейдите на вкладку “Безопасность“:

Там нажмите кнопку “Дополнительно” и перейдите на вкладку “Аудит“.

Затем нажмите кнопки “Продолжить” и “Добавить” и в открывшимся окне нажмите на ссылку “Выберите субъект“:

В открывшимся окне впишите логин своего пользователя и нажмите кнопку “Проверить имя“. Если ввели логин верно, то в списке пользователей отобразиться имя вашего пользователя:

Теперь нажмите на кнопку “ОК“, и выставьте все флажки в области “Особые разрешения” и ещё раз нажмите на кнопку “ОК“:

Затем нажмите ещё два раза на кнопку “ОК“, чтобы закрыть дополнительные параметры безопасности и свойства файла.

Дальше запустите оснастку secpol.msc и перейдите в “Локальные политики“. Там откройте “Аудит доступа к объектам” и поставьте флажок “Успех“, затем нажмите “ОК“:

Итак, политику аудита мы включили и на файле аудит настроили. Теперь откройте файл, запишите в него что нибудь и закройте сохранив изменения. Затем откройте журнал “eventvwr.exe” и перейдите в “Журналы Windows / Безопасность“:

Найдите событие с кодом 4656 — это и есть доступ к вашему файлу:

В событии вы увидите:

• ИД безопасности — это ваша учетная запись.
• Тип объекта — File.
• Имя объекта — путь к файлу.
• Имя процесса — путь к файлу программы (System32notepad.exe).
• Ключевые слова — Аудит успеха.
• И другую информацию.

Глобальная политика аудита

Настраивать для каждого файла аудит безопасности не всегда удобно. Иногда нужно включить аудит безопасности для всех файлов или для всех разделов реестра разом. Делается это через командную строку.

Чтобы посмотреть краткую информацию о командах для настройки и запроса политики глобального аудита выполните:

>auditpol /resourceSACL

Чтобы посмотреть глобальные списки SACL для файловой системы и для реестра выполните такие команды:

>auditpol /resourceSACL /type:File /view
>auditpol /resourceSACL /type:Key /view

Для установки аудита всех файлов с доступом на запись (FW) выполните:

> auditpol.exe /resourceSACL /set /type:File /user:<username> /success /failure /access:FW

В примере выше вместо имени пользователя можно ввести группу.

Чтобы выключить глобальный аудит, включенный предыдущей командой, выполните:

> auditpol.exe /resourceSACL /remove /type:File /user:<username>

Конфигурация расширенной политики аудита

В оснастке “Локальная политика безопасности” можно настроить конфигурацию расширенной политики аудита:

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

А “Аудит доступа к глобальным объектам” включает или отключает глобальные SACL, которые мы включали ранее из командной строки:

При включении “Аудита доступа к глобальным объектам” этот параметр нужно будет настроить, указав пользователей для аудита и тип доступа, в общем то что мы делали в командной строке выше:

---

Вернуться к оглавлению

Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.

1. Введение
2. Знакомство с расширенным аудитом Windows
3. Настройка политик аудита
4. Усиление цифровой обороны
5. Выводы

Введение

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

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

 

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

 

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

 

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Категория (Category)	Подкатегория (Subcategory)
Вход учётной записи (Account Logon)	Аудит проверки учётных данных (Audit Credential Validation)
Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service)
Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations)
Аудит других событий входа учётных записей (Audit Other Account Logon Events)
Управление учётными записями (Account Management)	Аудит управления группами приложений (Audit Application Group Management)
Аудит управления учётными записями компьютеров (Audit Computer Account Management)
Аудит управления группами распространения (Audit Distribution Group Management)
Аудит других событий управления учётными записями (Audit Other Account Management Events)
Аудит управления группами безопасности (Audit Security Group Management)
Аудит управления учётными записями пользователей (Audit User Account Management)
Подробное отслеживание (Detailed Tracking)	Аудит активности DPAPI (Audit DPAPI Activity)
PNP-действие аудита (Audit PNP Activity)
Аудит создания процессов (Audit Process Creation)
Аудит завершения процессов (Audit Process Termination)
Аудит событий RPC (Audit RPC Events)
Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше]
Доступ к службе каталогов DS (DS Access)	Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication)
Аудит доступа к службе каталогов (Audit Directory Service Access)
Аудит изменения службы каталогов (Audit Directory Services Changes)
Аудит репликации службы каталогов (Audit Directory Service Replication)
Вход / выход (Logon / Logoff)	Аудит блокировки учётных записей (Audit Account Lockout)
Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims)
Аудит расширенного режима IPsec (Audit IPsec Extended Mode)
Аудит основного режима IPsec (Audit IPsec Main Mode)
Аудит быстрого режима IPsec (Audit IPsec Quick Mode)
Аудит выхода из системы (Audit Logoff)
Аудит входа в систему (Audit Logon)
Аудит сервера политики сети (Audit Network Policy Server)
Аудит других событий входа и выхода (Audit Other Logon / Logoff Events)
Аудит специального входа (Audit Special Logon)
Доступ к объектам (Object Access)	Аудит событий, создаваемых приложениями (Audit Application Generated)
Аудит служб сертификации (Audit Certification Services)
Аудит сведений об общем файловом ресурсе (Audit Detailed File Share)
Аудит общего файлового ресурса (Audit File Share)
Аудит файловой системы (Audit File System)
Аудит подключения платформы фильтрации (Audit Filtering Platform Connection)
Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop)
Аудит работы с дескрипторами (Audit Handle Manipulation)
Аудит объектов ядра (Audit Kernel Object)
Аудит других событий доступа к объектам (Audit Other Object Access Events)
Аудит реестра (Audit Registry)
Аудит съёмного носителя (Audit Removable Storage)
Аудит диспетчера учётных записей безопасности (Audit SAM)
Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging)
Изменение политики (Policy Change)	Аудит изменения политики аудита (Audit Policy Change)
Аудит изменения политики проверки подлинности (Audit Authentication Policy Change)
Аудит изменения политики авторизации (Audit Authorization Policy Change)
Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change)
Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change)
Аудит других событий изменения политики (Audit Other Policy Change Events)
Использование привилегий (Privilege Use)	Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use)
Аудит других событий использования привилегий (Audit Other Privilege Use Events)
Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use)
Система (System)	Аудит драйвера IPsec (Audit IPsec Driver)
Аудит других системных событий (Audit Other System Events)
Аудит изменения состояния безопасности (Audit Security State Change)
Аудит расширения системы безопасности (Audit Security System Extension)
Аудит целостности системы (Audit System Integrity)
Аудит доступа к глобальным объектам (Global Object Access Auditing)	Файловая система (File system)
Реестр (Registry)

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

 

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

 

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

 

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

 

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

 

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

 

Настройка политик аудита

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

Категория	Подкатегория	Включить	Хост (DC, сервер, АРМ)	Категория (успех / отказ)
Account Logon	Audit Credential Validation	+	DC, сервер, АРМ	Успех и отказ
Audit Kerberos Authentication Service	+	DC	Успех и отказ
Audit Kerberos Service Ticket Operations	+	DC	Успех и отказ
Audit Other Account Logon Events	—
Account Management	Audit Application Group Management	+	DC	Успех и отказ
Audit Computer Account Management	+	DC	Успех
Audit Distribution Group Management	+	DC	Успех
Audit Other Account Management Events	+	DC, сервер, АРМ	Успех
Audit Security Group Management	+	DC, сервер, АРМ	Успех
Audit User Account Management	+	DC, сервер, АРМ	Успех и отказ
Detailed Tracking	Audit DPAPI Activity	+	DC, сервер, АРМ	Успех и отказ
Audit PNP Activity	+	DC, сервер, АРМ	Успех и отказ
Audit Process Creation	+	DC, сервер, АРМ	Успех
Audit Process Termination	—
Audit RPC Events	—
Audit Token Right Adjusted	—
DS Access	Audit Detailed Directory Service Replication	+	DC	Успех и отказ
Audit Directory Service Access	+	DC	Успех и отказ
Audit Directory Services Changes	+	DC	Успех и отказ
Audit Directory Service Replication	+	DC	Успех и отказ
Logon/Logoff	Audit Account Lockout	+	DC, сервер, АРМ	Отказ
Audit User / Device Claims	—
Audit IPsec Extended Mode	—
Audit IPsec Main Mode	—
Audit IPsec Quick Mode	—
Audit Logoff	+	DC, сервер, АРМ	Успех
Audit Logon	+	DC, сервер, АРМ	Успех и отказ
Audit Network Policy Server	—
Audit Other Logon / Logoff Events	+	DC, сервер, АРМ	Успех и отказ
Audit Special Logon	+	DC, сервер, АРМ	Успех
Object Access	Audit Application Generated	—
Audit Certification Services	—
Audit Detailed File Share	—
Audit File Share	—
Audit File System	+	DC, сервер, АРМ	Успех и отказ
Audit Filtering Platform Connection	—
Audit Filtering Platform Packet Drop	—
Audit Handle Manipulation	—
Audit Kernel Object	—
Audit Other Object Access Events	+	DC, сервер, АРМ	Успех и отказ
Audit Registry	+	DC, сервер, АРМ	Успех и отказ
Audit Removable Storage	+	DC, сервер, АРМ	Успех и отказ
Audit SAM	—
Audit Central Access Policy Staging	—
Policy Change	Audit Policy Change	+	DC, сервер, АРМ	Успех
Audit Authentication Policy Change	+	DC, сервер, АРМ	Успех
Audit Authorization Policy Change	+	DC, сервер, АРМ	Успех
Audit Filtering Platform Policy Change	—
Audit MPSSVC Rule-Level Policy Change	+	DC, сервер, АРМ	Успех и отказ
Audit Other Policy Change Events	—
Privilege Use	Audit Non Sensitive Privilege Use	+	DC, сервер, АРМ	Успех и отказ
Audit Other Privilege Use Events	—
Audit Sensitive Privilege Use	+	DC, сервер, АРМ	Успех и отказ
System	Audit IPsec Driver	—
Audit Other System Events	+	DC, сервер, АРМ	Успех и отказ
Audit Security State Change	+	DC, сервер, АРМ	Успех
Audit Security System Extension	+	DC, сервер, АРМ	Успех
Audit System Integrity	—
Global Object Access Auditing	File system	—
Registry	—

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

Усиление цифровой обороны

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

Рисунок 10. Журналирование командной строки процесса

 

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

 

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

 

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

 

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

 

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

 

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

 

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

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

Рисунок 17. Настройка хранения журналов аудита

 

Выводы

Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.