Microsoft windows security auditing что это такое

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

Что такое аудит безопасности в Windows?

Аудит безопасности Windows — это технические средства и мероприятия, направленные на регистрацию и систематический регулярный анализ событий,
влияющих на безопасность информационных систем предприятия.
Технически, аудит безопасности в Windows реализуется через настройку политик аудита и настройку аудита объектов.
Политика аудита определяет какие события и для каких объектов будут генерироваться в журнал событий Безопасность.
Регулярный анализ данных журнала безопасности относится к организационным мерам, для поддержки которых может применяться различное программное обеспечение.
В самом простом случае можно обходиться приложением Просмотр событий.
Для автоматизации задач анализа событий безопасности могут применяться более продвинутые программы и системы управления событиями безопасности (SIEM),
обеспечивающие постоянный контроль журналов безопасности, обнаружение новых событий, их классификацию, оповещение специалистов при обнаружении критических событий.
Наша программа Event Log Explorer также содержит набор функций для автоматизации мониторинга событий для любых журналов событий.

See also: Security event log

Как установить и настроить аудит безопасности в Windows?

Аудит безопасности Windows включается через Групповую политику (Group Policy) в Active Directory или Локальную политику безопасности.
Чтобы настроить аудит на отдельном компьютере, без Active Directory, выполните следующие шаги:

• Откройте Панель управления Windows, выберите Администрирование (Administrative Tools), и затем запустите Локальная политика безопасности (Local Security Policy)
• Откройте ветвь Локальные политики и выберите Политика Аудита
• В правой панели окна Локальная политика безопасности (Local Security Policy) вы увидите список политик аудита. Двойным кликом на интересующей вас политике откройте параметры и установите флажки Аудит успехов или Аудит отказов (Success or Failure).

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

Начиная с Windows 2008 R2/Windows 7, вы можете использовать Расширенные политики (Advanced Security Audit Policy):

Local Security Policy -> Advanced Audit Policy Configuration -> System Audit Policies.
Подробная информация про расширенные политики (Advanced Security Audit Policy) доступна тут https://technet.microsoft.com/en-us/library/dn319056.aspx

Как контролировать события входа в Windows?

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

Для отдельного компьютера (без Active Directory) аудит событий входа настраивается так:

• Откройте ветвь Локальные политики (Local Policies) в Локальная политика безопасности (Local Security Policy)
• Выберите Audit Policy.
• Двойным кликом откройте Аудит событий входа (Audit logon events) и включите опции аудита успехов и отказов (Success и Failure).

После этого все попытки входа — успешные и неудачные будут протоколироваться в журнал событий Безопасность

Список кодов важных событий входа в систему

Event ID	Текст описания события
4624	Вход с учетной записью выполнен успешно
4625	Не удалось выполнить вход с учетной записью
4648	Попытка входа в систему, используя явные учетные данные
4675	Идентификаторы безопасности были отфильтрованы

Подробнее с кодами событий безопасности можно ознакомиться тут https://support.microsoft.com/ru-ru/kb/977519

Как контролировать события доступа к файлам?

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

Подробнее с кодами событий безопасности можно ознакомиться тут https://support.microsoft.com/ru-ru/kb/977519

В статье рассмотрим то, как мы можем проводить аудит безопасности системы 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, которые мы включали ранее из командной строки:

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

---

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

ILYA Sazonov: ITPro

Windows XP

Свежие записи

Топ записей

Архивы

Подписка на email

Отключаем расширенную политику аудита

Не так давно мне нужно было отловить некоторые хитрые события связанные с аутентификацией на домен-контроллерах. Для решения этой задачи пришлось включить с помощью групповых политик так называемый расширенный аудит, который появился в Windows Server 2008 R2 и Windows 7. Можно настроить 53 события аудита! Есть где разгуляться!

Эти события пишутся в отдельный журнал Microsoft-Windows-Audit; при этом журнал Security больше не пополняется новыми событиями аудита – прежняя система аудита отключается полностью.

Когда мое исследование было завершено, я выставил параметры расширенного аудита в групповой политике в «Not configured». К моему удивлению после применения политик к домен-контроллерам в журнал Security события аудита не начали поступать – классическая система аудита не включилась. Загадка!

В библиотеке Technet была найдена статья, которая ясно описывала шаги по отключению расширенного аудита:

1.Set all Advanced Audit Policy sub-categories to Not configured.

2.Delete all audit.csv files from the %SYSVOL% folder on the domain controller.

3.Reconfigure and apply the basic audit policy settings.

И так первый шаг мной уже сделан. Удалил файл audit.csv и обновил политики на домен-контроллерах. Не помогло!

Поискал файл audit.csv локально на домен-контроллере и нашел в двух местах C:WindowsSystem32GroupPolicy и C:Windowssecurityaudit. Обновил политики – не помогло. Чудеса!

Ключевым оказалось слово Reconfigure из третьего пункта: каждую настройку классического аудита в групповой политике надо выключить, сохранить, включить заново и опять сохранить. Затем применить обновленную политику. (Может достаточно передернуть одну настройку аудита, чтобы раздел GPO обновился и применился?)

Сразу после этого в журнал Security на домен-контроллерах полетели события.

Не зря сказано: слово из песни не выбросишь!

Источник

Включение и отключение аудита

Журнал аудита будет включен по умолчанию для Microsoft 365 и Office 365 организаций. Однако при настройке Microsoft 365 или Office 365 организации необходимо проверить состояние аудита для организации. Инструкции см. в разделе Проверка состояния аудита для вашей организации в этой статье.

При включенном Центр соответствия требованиям Microsoft 365 аудите действия пользователя и администратора вашей организации записывают в журнал аудита и сохраняются в течение 90 дней и до одного года в зависимости от лицензии, назначенной пользователям. Однако у вашей организации могут быть причины, по которой вы не хотите записывать и хранить данные журнала аудита. В этих случаях глобальный администратор может принять решение отключить аудит в Microsoft 365.

Если вы отключите аудит в Microsoft 365, вы не можете использовать API Office 365 управления или Azure Sentinel для доступа к данным аудита для вашей организации. Отключение аудита, следуя шагам в этой статье, означает, что результаты не будут возвращены при поиске журнала аудита с помощью Центр соответствия требованиям Microsoft 365 или при запуске cmdlet Search-UnifiedAuditLog в Exchange Online PowerShell. Это также означает, что журналы аудита не будут доступны через API Office 365 управления или Azure Sentinel.

Прежде чем включить аудит или отключить

Для того чтобы включить или отключить аудит в Exchange Online организации, необходимо Exchange Online роли Microsoft 365 журналов аудита. По умолчанию эта роль назначена группам ролей управления соответствием требованиям и организации на странице Permissions в центре администрирования Exchange. Глобальные администраторы в Microsoft 365 являются членами группы ролей управления организацией в Exchange Online.

Пользователям должны быть назначены разрешения в Exchange Online, чтобы включить или отключить аудит. Если назначить пользователям роль журналов аудита на странице Разрешения в Центр соответствия требованиям Microsoft 365, они не смогут включить или отключить аудит. Это потому, что в основном cmdlet является Exchange Online PowerShell.

Пошаговая инструкция по поиску журнала аудита см. в журнале Поиска аудита. Дополнительные сведения об API Microsoft 365 управления см. в Microsoft 365 APIуправления.

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

Чтобы убедиться, что аудит включен для организации, можно выполнить следующую команду в Exchange Online PowerShell:

Значение свойства True UnifiedAuditLogIngestionEnabled указывает, что аудит включен. Значение False указывает, что аудит не включен.

Включи аудит

Если аудит не включен для организации, его можно включить в Центр соответствия требованиям Microsoft 365 или с помощью Exchange Online PowerShell. Может потребоваться несколько часов после того, как вы включит аудит, прежде чем вы сможете возвращать результаты при поиске журнала аудита.

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

В левой области навигации Центр соответствия требованиям Microsoft 365 нажмите кнопку Аудит.

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

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

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

Чтобы включить аудит, используйте PowerShell

Запустите следующую команду PowerShell, чтобы включить аудит.

Отображается сообщение о том, что для в действие изменения может потребоваться до 60 минут.

Отключение аудита

Чтобы отключить аудит Exchange Online PowerShell, необходимо использовать Exchange Online PowerShell.

Запустите следующую команду PowerShell, чтобы отключить аудит.

Через некоторое время убедитесь, что аудит отключен (отключен). Это можно сделать двумя способами:

В Exchange Online PowerShell запустите следующую команду:

Значение свойства False UnifiedAuditLogIngestionEnabled указывает на отключение аудита.

Перейдите на страницу Аудит в Центр соответствия требованиям Microsoft 365.

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

Записи аудита при смене состояния аудита

Изменения состояния аудита в организации сами проверяются. Это означает, что записи аудита регистрируются при включенной или отключенной проверке. Вы можете найти журнал аудита Exchange администратора для этих записей аудита.

Чтобы найти журнал аудита Exchange администратора для записей аудита, которые создаются при включании аудита или выключении, запустите следующую команду в Exchange Online PowerShell:

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

Запись аудита для включаемой проверки

Запись аудита для отключения аудита

Дополнительные сведения о поиске журнала аудита Exchange администратора см. в журнале Search-AdminAuditLog.

Источник

Проблемы в системе журналирования событий безопасности ОС 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!

Источник

Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности.

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

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

Справочники

Аудит. Немедленное отключение системы, если не удается войти в параметр политики аудита безопасности, определяет, закрывается ли система, если она не может войти в журнал событий безопасности. Этот параметр политики является требованием для доверенных критериев оценки компьютерной системы (TCSEC)-C2 и сертификации общих критериев, чтобы предотвратить возможность проведения аудита, если система аудита не может войти в журнал этих событий. Корпорация Майкрософт решила выполнить это требование, остановив систему и отобразив сообщение Stop в случае сбоя системы аудита. Включение этого параметра политики останавливает систему, если аудит безопасности не может быть зарегистрирован по какой-либо причине. Как правило, событие не удается войти в журнал аудита безопасности, **** когда журнал аудита безопасности заполнен и значение метода хранения для журнала безопасности не перезаписывать события (очистить журнал вручную) или перезаписывать события по дням .

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

Попытка создания аудита безопасности не удалась.

Чтобы восстановить, необходимо войти в систему, архивировать журнал (необязательно), очистить журнал и сбросить этот параметр по желанию.

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

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

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

Местонахождение

Конфигурация компьютераWindows ПараметрыSecurity ПараметрыLocal PoliciesSecurity Options

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

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

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

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

В этом разделе описываются функции и средства, доступные для управления этой политикой. Административное бремя включения этого параметра политики может быть очень **** высоким, особенно если вы также установите метод хранения для журнала безопасности, чтобы не перезаписывать события (очистить журнал вручную). Этот параметр превращает угрозу отказа (оператор резервного копирования может запретить резервное копирование или восстановление данных) в угрозу отказа в обслуживании, так как сервер может быть вынужден закрыться, если он перегружен событиями с логотипами и другими событиями безопасности, которые записаны в журнал безопасности. Кроме того, поскольку отключение не является изящным, не исключено, что может привести к непоправимым повреждениям операционной системы, приложений или данных. Несмотря на то, что файловая система NTFS гарантирует сохранение целостности файловой системы во время внезапного отключения системы, она не может гарантировать, что каждый файл данных для каждого приложения будет по-прежнему в годной форме при перезапуске системы.

Необходимость перезапуска

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

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

Изменение этого параметра может повлиять на совместимость с клиентами, службами и приложениями.

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

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

Уязвимость

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

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

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

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

Если включить этот параметр политики, административное бремя может быть **** значительным, особенно если также настроить метод хранения журнала безопасности, чтобы не перезаписывать события (очистить журнал вручную). Эта конфигурация вызывает угрозу отказа (оператор резервного копирования может отрицать, что они резервное копирование или восстановление данных) становится уязвимостью отказа в обслуживании (DoS), так как сервер может быть вынужден закрыться, если он перегружен событиями с логотипами и другими событиями безопасности, которые записаны в журнал событий безопасности. Кроме того, поскольку отключение является резким, не исключено, что может привести к непоправимым повреждениям операционной системы, приложений или данных. Несмотря на то, что файловая система NTFS сохраняет целостность при остановке компьютера такого типа, нет никакой гарантии того, что каждый файл данных для каждого приложения будет по-прежнему в годной форме при перезапуске устройства.

Источник