Файл открыт в журнале событий windows

Доброго дня!

Даже если вы за компьютером ничего не делаете — в процессе работы ОС Windows записывает часть данных в спец. документы (их еще называют логами или системными журналами). Как правило, под-запись попадают различные события, например, включение/выключение ПК, возникновение ошибок, обновления и т.д. 👀

Разумеется, в некоторых случаях эти записи могут быть очень полезными. Например, при поиске причин возникновения ошибок, синих экранов, внезапных перезагрузок и т.д. Отмечу, что если у вас установлена не официальная версия Windows — может так стать, что журналы у вас отключены… 😢

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

Итак…

*

Работа с журналом событий (для начинающих)

❶

Как его открыть

Вариант 1

Этот вариант универсальный и работает во всех современных версиях ОС Windows.

1. нажать сочетание кнопок Win+R — должно появиться окно «Выполнить»;
2. ввести команду eventvwr и нажать OK (примечание: также можно воспользоваться диспетчером задач (Ctrl+Shift+Esc) — нажать по меню «Файл/новая задача» и ввести ту же команду eventvwr);

   

   eventvwr — команда для вызова журнала событий

3. после этого у вас должно появиться окно «Просмотр событий» — обратите внимание на левую колонку, в ней как раз и содержатся всевозможные журналы Windows…

   

   Просмотр событий

Вариант 2

1. сначала необходимо 👉 открыть панель управления и перейти в раздел «Система и безопасность»;

   

   Система и безопасность

2. далее необходимо перейти в раздел «Администрирование»;

   

   Администрирование

3. после кликнуть мышкой по ярлыку «Просмотр событий».

   

   Просмотр событий — Администрирование

Вариант 3

Актуально для пользователей Windows 10/11.

1) Нажать по значку с «лупой» на панели задач, в поисковую строку написать «событий» и в результатах поиска ОС Windows предоставит вам ссылку на журнал (см. скрин ниже). 👇

2) Еще один способ: нажать сочетание Win+X — появится меню со ссылками на основные инструменты, среди которых будет и журнал событий.

❷

Журналы Windows

Наибольшую пользу (по крайней мере, для начинающих пользователей) представляет раздел «Журналы Windows» (выделен на скрине выше). Довольно часто при различных неполадках приходится изучать как раз его.

В нем есть 5 вкладок, из которых 3 основных: «Приложение», «Безопасность», «Система». Именно о них пару слов подробнее:

1. «Приложение» — здесь собираются все ошибки (и предупреждения), которые возникают из-за работы программ. Вкладка будет полезна в тех случаях, когда у вас какое-нибудь приложение нестабильно работает;
2. «Система» — в этой вкладке содержатся события, которые сгенерированы различными компонентами ОС Windows (модули, драйверы и пр.);
3. «Безопасность» — события, относящиеся к безопасности системы (входы в учетную запись, раздача прав доступа папкам и файлам, и т.д.).

❸

Как найти и просмотреть ошибки (в т.ч. критические)

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

И так, сначала необходимо выбрать нужный журнал (например «Система»), далее кликнуть в правой колонке по инструменту «Фильтр текущего журнала».

После указать дату, уровень события (например, ошибки), и нажать OK.

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

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

Т.е. как видите из примера — использование журнала событий очень даже помогает в решении самых разных проблем с ПК.

❹

Можно ли отключить журналы событий

Можно! Только нужно ли? (хотя не могу не отметить, что многие считают, что на этом можно сэкономить толику дискового пространства, плюс система более отзывчива и меньше нагрузка на жесткий диск) 

*

Для отключения журналов событий нужно:

1. открыть «службы» (для этого нажмите Win+R, введите команду services.msc и нажмите OK);

   

   Открываем службы — services.msc (универсальный способ)

2. далее нужно найти службу «Журнал событий Windows» и открыть ее;

   

   Службы — журналы событий

3. после перевести тип запуска в режим «отключена» и нажать кнопку «остановить». Затем сохранить настройки и перезагрузить компьютер.

   

   Отключена — остановить

*

На этом пока всё, удачи!

✌

Первая публикация: 23.03.2019

Корректировка: 14.08.2021

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

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

Физически Журнал событий представляет собой набор файлов в формате EVTX, хранящихся в системной папке %SystemRoot%/System32/Winevt/Logs.

Хотя эти файлы содержат текстовые данные, открыть их Блокнотом или другим текстовым редактором не получится, поскольку они имеют бинарный формат. Тогда как посмотреть Журнал событий в Windows 7/10, спросите вы? Очень просто, для этого в системе предусмотрена специальная штатная утилита eventvwr.

Как открыть журнал

Запустить утилиту можно из классической Панели управления, перейдя по цепочке Администрирование – Просмотр событий или выполнив в окошке Run (Win+R) команду eventvwr.msc.

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

Наибольший интерес представляет раздел «Журналы Windows», именно с ним чаще всего приходится работать, выясняя причины неполадок в работе системы и программ. Журнал системных событий включает три основных и две дополнительных категории. Основные это «Система», «Приложения» и «Безопасность», дополнительные – «Установка» и «Перенаправленные события».

Категория «Система» содержит события, сгенерированные системными компонентами – драйверами и модулями Windows.

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

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

Так как число событий может исчисляться тысячами и даже десятками тысяч, в eventvwr предусмотрена возможность поиска и фильтрации событий по свойствам – важности, времени, источнику, имени компьютера и пользователя, коду и так далее. Допустим, вы хотите получить список системных ошибок. Выберите слева Журналы Windows – Система, справа нажмите «Фильтр текущего журнала» и отметьте в открывшемся окне галочкой уровень события – пункты «Ошибка» и «Критическое». Нажмите «OK» и утилита тут же отфильтрует записи.

Чтобы просмотреть конкретную запись, кликните по ней дважды – сведения откроются в окошке «Свойства событий».

Как использовать содержимое журнала

Хорошо, теперь мы в курсе, где находится журнал событий и как его открыть, осталось узнать, как его можно использовать. Сразу нужно сказать, что в силу своей специфичности содержащиеся в нем сведения мало что могут поведать обычному пользователю. О чем говорит, к примеру, ошибка «Регистрация сервера {BF6C1E47-86EC-4194-9CE5-13C15DCB2001} DCOM не выполнена за отведенное время ожидания»? Не обладающему соответствующими знаниями юзеру будет непросто определить причину неполадки, с другой стороны, что мешает поискать ответ в Интернете?

Так, описание приведенной выше ошибки имеется на сайте Microsoft и указывает оно на проблемы со SkyDrive, кстати, не представляющие совершенно никакой угрозы. Если вы не пользуетесь этим сервисом, ошибку можно игнорировать или отключить ее источник в «Планировщике заданий». А еще описание ошибки можно отправить разработчику, предварительно сохранив его в файл XML, CSV или TХT.

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

Очистка, удаление и отключение журнала

На жестком диске файлы журнала занимают сравнительно немного места, тем не менее, у пользователя может возникнуть необходимость их очистить. Сделать это можно разными способами: с помощью оснастки eventvwr, командной строки и PowerShell. Для выборочной очистки вполне подойдет ручной способ. Нужно зайти в журнал событий, кликнуть ПКМ по очищаемому журналу в левой колонке и выбрать в меню опцию «Очистить журнал».

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

for /F “tokens=*” %1 in (‘wevtutil.exe el’) DO wevtutil.exe cl “%1”

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

wevtutil el | Foreach-Object {wevtutil cl “$_”}

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

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

Командой services.msc откройте оснастку «Службы», справа найдите «Журнал событий 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 : 4.5

Оценок: 4

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

+7 (812) 403-06-99

700
300

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

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

+7 (812) 403-06-99

700
300

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

700
300

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

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

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

Как запустить журнал событий

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

Чтобы запустить журнал событий щелкаем правой кнопкой мыши по меню Пуск и выбираем пункт Просмотр событий из меню.

Категории событий

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

Категорий довольно много, но обычно при решении проблем приходится обращаться только к трем из них — Приложение, Безопасность и Система.

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

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

Типы событий

В журнале отображаются три основных типа событий.

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

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


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

Не стоит расстраиваться или впадать в панику если в журнале вы обнаружите предупреждения или ошибки. Более того я уверен, что вы их обязательно найдете и чем больше на компьютере установлено программ, тем больше подобных событий будет в журнале. Дело в том, что не всегда коммуникация между операционной системой и установленной в ней программой проходит удачно, в результате в журнале появляется соответствующая запись, хотя при этом подобное событие никак не повлияет на работу программы или Windows. Таких событий большинство и нет никакого смысла пытаться докопаться до сути каждой такой ошибки. Я бы даже сказал так — к журналу событий стоит обращаться только в том случае, если что-то пошло не так…

Когда использовать просмотр событий

Если в работе компьютера появились сбои, то тут в первую очередь и стоит заглянуть в Просмотр событий. Например, компьютера стал внезапно перезагружаться, зависать или периодически стал появляться так называемый «синий экран смерти» (BSoD). В подобных ситуациях журнал событий сможет подсказать направление для поиска причины проблемы.

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

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

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

Как сохранить журнал событий

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

Журнал можно сохранить, например,в файл в формате CSV и затем его можно будет открыть, например, с помощью Excel.

Где находятся файлы журнала событий

Сами файлы журналов событий Windows по умолчанию находятся на системном диске — C:\Windows\System32\winevt\Logs

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

Как очистить журнал событий

Если возникает необходимость очистить журнал событий, то сделать это можно в Просмотре событий — щелкаем на нужном разделе правой кнопкой мышкой и выбираем пункт «Очистить журнал…».

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

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

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

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

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

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

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

Возьмем Windows 7 и проинсталлируем ее с параметрами по умолчанию. Домен вводить не будем. Посмотрим настройки аудита событий безопасности. Для этого откроем оснастку «Локальные политики безопасности» (secpol.msc, или «Панель управления —> Администрирование —> Локальные политики безопасности») и посмотрим базовые настройки аудита («Параметры безопасности —> Локальные политики —> Политики аудита»).

Как видно, аудит не настроен. Теперь посмотрим расширенные политики аудита («Параметры безопасности —> Конфигурация расширенной политики аудита —> Политики аудита системы — Объект локальной групповой политики»).

Тут аудит тоже не настроен. Раз так, то по идее никаких событий безопасности в журналах быть не должно. Проверяем. Откроем журнал безопасности (eventvwr.exe, или «Панель управление —> Администрирование —> Просмотр событий»).

Вопрос: «Откуда в журнале безопасности события, если аудит вообще не настроен ?!»

Объяснение

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

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

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

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

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

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

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

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

1. Эффективные политики аудита — информация, хранящаяся в оперативной памяти и определяющая текущие параметры работы модулей операционной системы, реализующих функции аудита.
2. Сохраненные политики аудита — информация, хранящаяся в реестре по адресу HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv и используемая для определения эффективных политик аудита после перезагрузки системы.

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

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

Пример 1

Если запустить утилиту auditpol на просмотр параметров аудита:
auditpol /get /category:*, то будут отображены сохраненные параметры аудита, то есть те, что хранятся в реестре по адресу HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv.

Пример 2

Если же запустить эту же утилиту, но уже на установку параметров:
auditpol /set /category:*, то будут изменены эффективные настройки аудита и сохраненные параметры аудита.

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

Пример 3

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

Пример 4

Теперь администратор выполнил команду auditpol /clear и сбросил все настройки аудита. Затем он установил аудит файловой системы, выполнив команду auditpol /set /subcategory:"Файловая система". Теперь, если зайти в «Базовые политики аудита» оснастки «Локальные политики безопасности», то все категории будут определены в состояние «Нет аудита», так как ни одна категория расширенной политики аудита не определена полностью.

Сейчас, наконец-то, мы сможем ответить на вопрос, откуда логи в свежеустановленной операционной системе. Все дело в том, что после инсталляции аудит в Windows настроен и определен в сохраненных параметрах аудита. В этом можно убедиться, выполнив команду auditpol /get /category:*.

В «Базовых политиках аудита» оснастки «Локальные политики безопасности» эти сведения об аудите не отображаются, так как во всех категориях не определена одна или более подкатегорий. В «Расширенных политиках аудита» оснастки «Локальные политики безопасности» эти сведения не отображаются, так как оснастка работает только c параметрами аудита, хранящимися в файле %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv.

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

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

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

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

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

1. На атакуемой рабочей станции предоставили себе права на запись к ключу реестра HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv и экспортировали этот ключ в файл c именем «+fs.reg».
2. На другом компьютере импортировали данный файл, перезагрузились, а затем с помощью auditpol отключили аудит файловой системы, после чего экспортировали указанный выше ключ реестра в файл «-fs.reg».
3. На атакуемой машине импортировали в реестр файл «-fs.reg».
4. Создали резервную копию файла %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv, расположенного на атакуемой машине, а затем удалили из него подкатегорию «Файловая система».
5. Перезагрузили атакуемую рабочую станцию, а затем подменили на ней файл %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv ранее сохраненной резервной копией, а также импортировали в реестр файл «+fs.reg»

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

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

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

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

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

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

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

«HandleId» = «HandleId события 1»
«System\EventRecordID» = «System\EventRecordID из события 1» + 1.

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

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

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

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

1. Если файл удаляется в корзину, то как и раньше — последовательностью событий 4663 и 4660.
2. Если же файл удаляется безвозвратно (мимо корзины), то одиночным событием с кодом 4659.

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

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

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

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

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

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

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

1. В событиях, генерируемых системой во время переименования, нигде не фиксируется новое имя объекта.
2. Процедура переименования очень похожа на удаление. Отличить ее можно только по тому, что за первым событием с кодом 4663, с параметром «AcessMask» = 0x10000 (DELETE) не идет событие 4660.

Стоит отметить, что применительно к реестру эта проблема распространяется только на ключи (keys). Переименование значений (value) в реестре описывается последовательностью событий 4657 и подобных нареканий не вызывает, хотя, конечно, было бы гораздо удобней, если бы было только одно событие.

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

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

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

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

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

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

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

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

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

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

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

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

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

Симптомы

Изменение расширенных политик безопасности не оказывает никакого влияния на эффективные параметры аудита, или, другими словами, политики не применяются. Например, администратор активировал подкатегорию «Вход в систему», перезагрузил систему, запускает команду auditpol /get /category:*, а данная подкатегория остается не активной. Проблема актуальна как для доменных компьютеров, управляемых через групповые политики, так и для не доменных, управляемых с помощью локального объекта групповой политики, конфигурируемого через оснастку «Локальные политики безопасности».

Причины

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

1. Использование прав —> Аудит использования прав, затрагивающих конфиденциальные данные. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
2. Использование прав —> Аудит использования прав, не затрагивающих конфиденциальные данные. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
3. Доступ к объектам —> Аудит событий, создаваемых приложениями. GUID:{ 0cce9222-69ae-11d9-bed3-505054503030}.

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

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

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

1. Из каталога доменной групповой политики удалить файл \Machine\microsoft\windows nt\Audit\audit.csv
2. Со всех компьютеров, на которых были выявлены проблемы с аудитом, удалить файлы: %SystemRoot%\security\audit\audit.csv, %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv

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

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

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

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

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

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

Подготовительная часть:

1. Возьмем свежеустановленную Windows 7.
2. Сбросим все настройки аудита с помощью команды auditpol /clear. Данный пункт необязательный и служит только для удобства анализа журналов.
3. Установим аудит файловой системы, выполнив команду auditpol /set /subcategory:"Файловая система".
4. Создадим каталог C:\TEST и назначим ему параметры аудита для учетной записи «Все»: «Создание файлов / Запись данных», «Создание папок / Дозапись данных», «Запись атрибутов», «Запись дополнительных атрибутов», «Удаление вложенных папок и файлов», «Удаление», «Смена разрешений», «Смена владельца», то есть все, что связано с записью данных в файловую систему.

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

Эксперимент 1.
Делаем:

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

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

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

Эксперимент 2.
Делаем:

Через «Проводник» откроем папку C:\TEST и с помощью контекстного меню «Создать —> Текстовый документ», вызываемому по клику правой кнопки мыши, создаем файл «Новый текстовый документ.txt».

Наблюдаем:

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

Эксперимент 3.
Делаем:

Через «Проводник» откроем папку C:\TEST и с помощью контекстного меню «Создать —> Документ в формате RTF», вызываемому по клику правой кнопки мыши, создаем файл «Новый документ в формате RTF.rtf».

Наблюдаем:

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

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

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

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

Заключение

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

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

MAKE WINDOWS SECURITY EVENT LOGGING GREAT AGAIN!