Один или несколько журналов запроса содержат ошибки

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

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

Как найти журналы через проводник

Чтобы просмотреть все файлы журналов, хранящиеся на вашем компьютере, откройте Проводник и выберите свой C: диск (или любая другая буква вашего основного диска). Тип *.журнал в поле поиска и нажмите Войти. Это просканирует весь ваш жесткий диск на наличие Windows и журналов программ. Этот процесс может занять несколько минут.

Скорее всего, будут тысячи результатов во многих разных папках, поэтому разумно отфильтровать список, чтобы отображались только самые последние события. Щелкните значок Дата изменена на панели инструментов проводника и выберите Сегодня, вчера, или же Эта неделя.

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

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

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

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

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

Ищите журналы с пометкой Предупреждение (что обычно означает, что произошло что-то неожиданное), ошибка (что-то не удалось) или Критический (что-то срочно требует решения). Чтобы не просматривать весь список, щелкните значок Посмотреть меню и выберите Сортировать по> Уровню размещать журналы, связанные с проблемами, вверху.

Либо, чтобы отфильтровать журналы по дате и серьезности, щелкните Фильтр текущего журнала в Действия раздел. Выберите вариант из Зарегистрировано меню, например Последние 24 часа или же Последние семь дней. Установите флажки для ошибка и Критический и нажмите Хорошо.

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

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

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

Как просматривать журналы с помощью SnakeTail

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

Скачать: SnakeTail для Windows 10 (Свободный)

Идти к Файл> Открыть журнал событий и выберите тип журнала, который нужно открыть, например «Приложение» или «Система». SnakeTail имеет интерфейс с вкладками, поэтому вы можете просматривать несколько списков журналов одновременно.

SnakeTail не только мгновенно загружает журналы, но и упрощает их фильтрацию. Щелкните правой кнопкой мыши уровень (например, Ошибка), дату или источник и выберите Добавить фильтр чтобы показать только релевантные результаты. Выберите событие, чтобы просмотреть подробности в разделе ниже.

Как просматривать журналы с FullEvenLogView

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

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

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

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

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

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

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

Решение конкретных проблем с помощью журналов

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

К счастью, помощь всегда под рукой на отличном сайте под названием EventID.Net. Это не только объясняет, что на самом деле означают конкретные события Windows, но и показывает, насколько они серьезны (или нет), и дает советы по устранению неполадок, которые вам нужны.

Скопируйте и вставьте журнал ID события номер из средства просмотра событий (или SnakeTail) в поле поиска на домашней странице EventID.Net вместе с Источник (программа или услуга). Например, если вы столкнулись с синим экраном смерти (BSoD), идентификатор события обычно равен 41, но источник может быть другим (часто используется Kernel-Power).

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

На момент написания обширная база данных EventID.Net охватывает 11 588 идентификаторов событий Windows и 638 источников событий с 19 234 комментариями. Сайт можно использовать бесплатно, но для некоторых функций, таких как изменение описания событий на простом английском языке, требуется платная подписка.

Если EventID.Net не помогает или журнал не предоставляет идентификационный номер, лучше всего скопировать и вставить сводку события в Google или Сообщество Microsoft сайт. Кто-то другой, вероятно, столкнулся с той же проблемой.

Верьте в силу бревен

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

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

Один или несколько журналов запроса содержат ошибки, File Replication Service отказано в доступе.

 

 

Такую ошибку получил когда пытался настроить роль DFS на Windows 2008 R2. В логах к этой ошибке есть еще куча всяких сообщений о проблемах с dhcp и прочее. Вариантов решения предлагалось много и это, по сути верно, вначале надо разобраться с проблемами dhcp, dns и т.д.

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

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

В операционных системах семейства 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_MACHINESECURITYPolicyPolAdtEv и используемая для определения эффективных политик аудита после перезагрузки системы.

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

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

Пример 1

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

Пример 2

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

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

Пример 3

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

Пример 4

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

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

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

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

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

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

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

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

1. На атакуемой рабочей станции предоставили себе права на запись к ключу реестра HKEY_LOCAL_MACHINESECURITYPolicyPolAdtEv и экспортировали этот ключ в файл c именем «+fs.reg».
2. На другом компьютере импортировали данный файл, перезагрузились, а затем с помощью auditpol отключили аудит файловой системы, после чего экспортировали указанный выше ключ реестра в файл «-fs.reg».
3. На атакуемой машине импортировали в реестр файл «-fs.reg».
4. Создали резервную копию файла %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.csv, расположенного на атакуемой машине, а затем удалили из него подкатегорию «Файловая система».
5. Перезагрузили атакуемую рабочую станцию, а затем подменили на ней файл %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.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»
«SystemEventRecordID» = «SystemEventRecordID из события 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. Из каталога доменной групповой политики удалить файл Machinemicrosoftwindows ntAuditaudit.csv
2. Со всех компьютеров, на которых были выявлены проблемы с аудитом, удалить файлы: %SystemRoot%securityauditaudit.csv, %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.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!

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

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

Как найти журналы через проводник

Чтобы просмотреть все файлы журналов, хранящиеся на вашем компьютере, откройте Проводник и выберите свой C: диск (или любая другая буква вашего основного диска). Тип *.журнал в поле поиска и нажмите Войти. Это просканирует весь ваш жесткий диск на наличие Windows и журналов программ. Этот процесс может занять несколько минут.

Скорее всего, будут тысячи результатов во многих разных папках, поэтому разумно отфильтровать список, чтобы отображались только самые последние события. Щелкните значок Дата изменена на панели инструментов проводника и выберите Сегодня, вчера, или же Эта неделя.

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

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

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

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

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

Ищите журналы с пометкой Предупреждение (что обычно означает, что произошло что-то неожиданное), ошибка (что-то не удалось) или Критический (что-то срочно требует решения). Чтобы не просматривать весь список, щелкните значок Посмотреть меню и выберите Сортировать по> Уровню размещать журналы, связанные с проблемами, вверху.

Либо, чтобы отфильтровать журналы по дате и серьезности, щелкните Фильтр текущего журнала в Действия раздел. Выберите вариант из Зарегистрировано меню, например Последние 24 часа или же Последние семь дней. Установите флажки для ошибка и Критический и нажмите Хорошо.

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

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

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

Как просматривать журналы с помощью SnakeTail

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

Скачать: SnakeTail для Windows 10 (Свободный)

Идти к Файл> Открыть журнал событий и выберите тип журнала, который нужно открыть, например «Приложение» или «Система». SnakeTail имеет интерфейс с вкладками, поэтому вы можете просматривать несколько списков журналов одновременно.

SnakeTail не только мгновенно загружает журналы, но и упрощает их фильтрацию. Щелкните правой кнопкой мыши уровень (например, Ошибка), дату или источник и выберите Добавить фильтр чтобы показать только релевантные результаты. Выберите событие, чтобы просмотреть подробности в разделе ниже.

Как просматривать журналы с FullEvenLogView

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

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

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

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

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

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

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

Решение конкретных проблем с помощью журналов

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

К счастью, помощь всегда под рукой на отличном сайте под названием EventID.Net. Это не только объясняет, что на самом деле означают конкретные события Windows, но и показывает, насколько они серьезны (или нет), и дает советы по устранению неполадок, которые вам нужны.

Скопируйте и вставьте журнал ID события номер из средства просмотра событий (или SnakeTail) в поле поиска на домашней странице EventID.Net вместе с Источник (программа или услуга). Например, если вы столкнулись с синим экраном смерти (BSoD), идентификатор события обычно равен 41, но источник может быть другим (часто используется Kernel-Power).

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

На момент написания обширная база данных EventID.Net охватывает 11 588 идентификаторов событий Windows и 638 источников событий с 19 234 комментариями. Сайт можно использовать бесплатно, но для некоторых функций, таких как изменение описания событий на простом английском языке, требуется платная подписка.

Если EventID.Net не помогает или журнал не предоставляет идентификационный номер, лучше всего скопировать и вставить сводку события в Google или Сообщество Microsoft сайт. Кто-то другой, вероятно, столкнулся с той же проблемой.

Верьте в силу бревен

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

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

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

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

Включение логирования

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

1. Нажмите в любом пустом месте «Панели задач» правой кнопкой мышки. Из контекстного меню выберите пункт «Диспетчер задач».



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



3. Далее в перечне служб нужно найти «Журнал событий Windows». Убедитесь, что она запущена и работает в автоматическом режиме. Об этом должны свидетельствовать надписи в графах «Состояние» и «Тип запуска».



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

После этого остается проверить, активирован ли на компьютере файл подкачки. Дело в том, что при его выключении система попросту не сможет вести учет всех событий. Поэтому очень важно установить значение виртуальной памяти хотя бы 200 Мб. Об этом напоминает сама Windows 10 в сообщении, которое возникает при полной деактивации файла подкачки.

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

Подробнее: Включение файла подкачки на компьютере с Windows 10

С включением логирования разобрались. Теперь двигаемся дальше.

Запуск «Просмотра событий»

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

1. Нажмите на клавиатуре одновременно клавишу «Windows» и «R».
2. В строку открывшегося окна введите eventvwr.msc и нажмите «Enter» либо же кнопку «OK» ниже.

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

Подробнее: Просмотр журнала событий в ОС Windows 10

Анализ журнала ошибок

После того как «Просмотр событий» будет запущен, вы увидите на экране следующее окно.

В левой его части находится древовидная система с разделами. Нас интересует вкладка «Журналы Windows». Нажмите на ее названии один раз ЛКМ. В результате вы увидите список вложенных подразделов и общую статистику в центральной части окна.

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

Критическое событие

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

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

Подробнее: Выключение системы Windows 10

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

Ошибка

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

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

Подробнее: Устанавливаем обновления для Windows 10 вручную

Предупреждение

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

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

Сведения

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

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

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

В операционных системах семейства 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_MACHINESECURITYPolicyPolAdtEv и используемая для определения эффективных политик аудита после перезагрузки системы.

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

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

Пример 1

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

Пример 2

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

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

Пример 3

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

Пример 4

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

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

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

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

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

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

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

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

1. На атакуемой рабочей станции предоставили себе права на запись к ключу реестра HKEY_LOCAL_MACHINESECURITYPolicyPolAdtEv и экспортировали этот ключ в файл c именем «+fs.reg».
2. На другом компьютере импортировали данный файл, перезагрузились, а затем с помощью auditpol отключили аудит файловой системы, после чего экспортировали указанный выше ключ реестра в файл «-fs.reg».
3. На атакуемой машине импортировали в реестр файл «-fs.reg».
4. Создали резервную копию файла %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.csv, расположенного на атакуемой машине, а затем удалили из него подкатегорию «Файловая система».
5. Перезагрузили атакуемую рабочую станцию, а затем подменили на ней файл %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.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»
«SystemEventRecordID» = «SystemEventRecordID из события 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. Из каталога доменной групповой политики удалить файл Machinemicrosoftwindows ntAuditaudit.csv
2. Со всех компьютеров, на которых были выявлены проблемы с аудитом, удалить файлы: %SystemRoot%securityauditaudit.csv, %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.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!

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

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

Включение логирования

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

1. Нажмите в любом пустом месте «Панели задач» правой кнопкой мышки. Из контекстного меню выберите пункт «Диспетчер задач».



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



3. Далее в перечне служб нужно найти «Журнал событий Windows». Убедитесь, что она запущена и работает в автоматическом режиме. Об этом должны свидетельствовать надписи в графах «Состояние» и «Тип запуска».



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

После этого остается проверить, активирован ли на компьютере файл подкачки. Дело в том, что при его выключении система попросту не сможет вести учет всех событий. Поэтому очень важно установить значение виртуальной памяти хотя бы 200 Мб. Об этом напоминает сама Windows 10 в сообщении, которое возникает при полной деактивации файла подкачки.

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

Подробнее: Включение файла подкачки на компьютере с Windows 10

С включением логирования разобрались. Теперь двигаемся дальше.

Запуск «Просмотра событий»

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

1. Нажмите на клавиатуре одновременно клавишу «Windows» и «R».
2. В строку открывшегося окна введите eventvwr.msc и нажмите «Enter» либо же кнопку «OK» ниже.

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

Подробнее: Просмотр журнала событий в ОС Windows 10

Анализ журнала ошибок

После того как «Просмотр событий» будет запущен, вы увидите на экране следующее окно.

В левой его части находится древовидная система с разделами. Нас интересует вкладка «Журналы Windows». Нажмите на ее названии один раз ЛКМ. В результате вы увидите список вложенных подразделов и общую статистику в центральной части окна.

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

Критическое событие

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

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

Подробнее: Выключение системы Windows 10

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

Ошибка

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

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

Подробнее: Устанавливаем обновления для Windows 10 вручную

Предупреждение

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

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

Сведения

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

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

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