Event Log

Другие идентичные по назначению опции: Event Logging, Event Log Capacity.

Опция Event Log относится к категории опций, предназначенных для настройки журнала событий BIOS. Обычно данная опция позволяет включить или выключить этот журнал.

Принцип работы

Далеко не всегда наши компьютеры работают безупречно, как часы, и нередко возникают такие ситуации, когда пользователю ПК приходится иметь дело с той или иной неисправностью, связанной с аппаратной частью компьютера или с его программным обеспечением. И в подобных ситуациях зачастую трудно обойтись без такой вещи, как журнал событий (Event Log).

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

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

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

Включение функции записи лога событий осуществляется при помощи выбора варианта Enabled, а выключение – при помощи выбора варианта Disabled. Также в BIOS обычно присутствуют и другие опции, позволяющие работать с журналом, например, осуществлять его просмотр или очистку.

Стоит ли включать опцию?

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

Источник

Журнал событий (Event Logging)

Win32: централизованное протоколирование событий

Автор: Серебряков Алексей (Smooky)
QUIBECK INC.
Источник: RSDN Magazine #3-2007

Опубликовано: 14.11.2007
Исправлено: 10.12.2016
Версия текста: 1.0

Предисловие

Для решения этой проблемы операционная система Windows предоставляет такой сервис и программный интерфейс, как Eventlog. Этот инструментарий относится к числу базовых сервисов Windows, т.е. поставляется с самой системой и система сама же его использует. Стоит заметить, что эта возможность есть только у систем семейств WinNT/XP, т.к. приложение для протоколирования событий является сервисом. Также стоит заметить, что в Windows Vista и Windows Longhorn этот сервис существенно переработан, новый вариант в этой статье рассматриваться не будет.

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

Теория

Рисунок 1.

Наверное, почти все разработчики используют в своих программах протоколирование событий при выявлении ошибок, отладке и диагностировании приложений. Но даже после успешного сбора и просмотра статистики иной раз бывает сложно проанализировать, что же всё-таки случилось и в каком месте? Так вот, сервис «Журнал событий» является стандартным, централизованным способом сбора статистики и просмотра сообщений о событиях, поступающих от приложений, сервисов операционной системы и аппаратных устройств. Средство для просмотра этих событий является оснасткой Microsoft Management Console. В Windows XP Rus эта оснастка запускается так: Пуск->Настройка->Панель управления->Администрирование->Просмотр Событий (Event Viewer).

ПРЕДУПРЕЖДЕНИЕ

При использовании сервиса протоколирования в журнал следует записывать достаточно важные и нужные сведения о происшедших ошибках, которые действительно потом могут помочь разработчикам разобраться, что же произошло с приложением. Не следует, например, писать в системный журнал с периодичностью 100нс сообщения о том, что пользователь случайно удалил файл readme.txt. Журнал событий – это не средство трассировки.

События в журнале

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

Тип события	Пояснение
Ошибка (Error)	Этим типом обычно определяется серьёзная ошибка приложения. Например, исполнение приложения прервалось из-за нехватки ресурсов.
Предупреждение (Warning)	Этим типом приложение обычно информирует о том, что скоро может возникнуть проблема, например, закончится дисковое пространство.
Информация (Information)	Этим типом приложение обычно информирует об успехе какой-либо важной операции, например, при старте сервиса.
Успешный отчёт (Success Audit)	Этот тип события обычно означает об успехе какой-либо операции доступа, например, пользователь вошёл в систему.
Не успешный отчёт (Fault Audit)	Этот тип события обычно означает, что произошла какая-то ошибка при доступе к ресурсу, например, пользователь не смог обратиться к сетевому диску.

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

СОВЕТ

Элементы журнала событий

Журналы

Всю информацию о настройках журнала сервис берёт из реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog.

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

Журнал (Log)	Пояснение
Приложение (Application)	Этот журнал содержит записи от приложений. Например, если мы зарегистрируем свой источник событий (т.е. приложение) и не укажем журнал, по умолчанию записи будут поступать сюда.
Система (System)	Этот журнал содержит записи, поступающие от системных служб. Но писать в него может любое приложение.
Безопасность (Security)	Этот журнал предназначен для аудита, например, событий входа пользователя в систему.
Другой (Custom)	Можно создать свой журнал. Не поддерживается в Windows NT.

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

Ключ в реестре	Пояснение
DisplayNameFile	Имя файла, в котором содержится локализованная строка с названием журнала, то есть строка, которую покажет Event Viewer. Если параметр не указан, Event Viewer в качестве строки покажет наименование подключа, в котором определён параметр. По умолчанию все локализованные ресурсы находятся в %SystemRoot%\system32\ELS.DLL. Строковый параметр.
DisplayNameID	Идентификатор строки в ресурсной DLL. Тип параметра DWORD.
File	Путь к папке, где Event Viewer будет хранить файлы журналов. По умолчанию это %SystemRoot%\system32\config\MyLogName, где MyLogName – имя журнала. При создании нового файла журнала сервис должен иметь права на полный доступ к файлу. Если значение этого параметра будет неверным, все записи будут перенаправляться в журнал Application. В пути нельзя использовать имя удалённого компьютера, DOS-устройства, дисководы, именованные каналы. Нельзя использовать переменные окружения, которые нельзя раскрыть в контексте сервиса.
MaxSize	Максимальный размер журнала в байтах. По умолчанию 512К. Параметр DWORD.
PrimaryModule	Наименование ключа, где хранятся настройки по умолчанию. Обычно совпадает с наименованием журнала. Строковый параметр.
Retention	Интервал в секундах, в течение которого записи могут остаться не перезаписанными. Если установлено в ноль, записи в журнале всегда перезаписываются, если не ноль или 0xFFFFFFFF, то записи никогда не перезаписываются. При достижении максимального размера журнал необходимо очистить вручную, иначе записи будут потеряны. Перед тем, как изменять это значение, журнал необходимо очистить. Параметр DWORD. По умолчанию – 0.
Sources	Список приложений, сервисов, которые могут писать в журнал. Только для чтения. Этот список создаёт сам сервис. Названия приложений берутся из текущей ветки журнала и разделяются null-terminated. Параметр многострочный.
AutoBackupLogFiles	Если значение параметра – 0, журнал не сохраняется как резервная копия. По умолчанию – 0.
RestrictGuestAccess	Если значение – 1, то пользователи под учётной записью Guest и Anonymous не имеют доступа к журналу. По умолчанию – 0.
Isolation	Не используется.

Источники событий

Каждая подветка в ветке Eventlog – это источник событий.

Например, для приложения MySuperApp.EXE, которое будет записывать события в журнал Application, необходимо создать такую подветку:

Здесь MySuperApp – это произвольное имя, по которому сервис (журнал) будет опознавать события, поступающие от нашего приложения. Каких либо соглашений об имени в документации не указано, но видимо, имя должно быть уникально в пределах одной подветки. Обычно используется название приложения или исполняемого модуля. По сути дела, это и есть регистрация приложения в сервисах Event Logging и Event Viewer.

Пользовательские приложения и сервисы должны либо регистрировать себя в журнале Application, либо создавать свой журнал. Журнал Security используется только системой. Драйверы устройств должны использовать журнал System.

Каждый источник событий (как мы уже знаем, приложение) должен в своей подветке определить перечисленные ключи. Они помогают Event Viewer сопоставлять сообщения и подставляемые параметры из ресурсной DLL-библиотеки с идентификаторами в приложении (позже я это продемонстрирую на примере):

Ключ в реестре	Пояснение
CategoryCount	Число используемых категорий. Тип DWORD.
CategoryMessageFile	Путь к файлу с локализованными строками, определяющими категории. Строковый параметр.
EventMessageFile	Путь к файлу с локализованными строками сообщений. Можно перечислить несколько файлов через запятую. Например, EVT_ENG.DLL, EVT_RUS.DLL. Строковый параметр.
ParameterMessageFile	Путь к файлу с локализованными строками параметров, подставляемых в текст сообщения. Строковый параметр.
TypeSupported	Параметр определяет типы поддерживаемых сообщений. Например, только ошибки и предупреждения: EVENTLOG_ERROR_TYPE \| EVENTLOG_WARNING_TYPE. Параметр DWORD определяет маску из следующих типов:EVENTLOG_ERROR_TYPE, EVENTLOG_WARNING_TYPE, EVENTLOG_INFORMATION_TYPE, EVENTLOG_AUDIT_SUCCESS, EVENTLOG_AUDIT_FAILURE

ПРЕДУПРЕЖДЕНИЕ

Однако если ветка была найдена, но не были определены файлы сообщений для найденного источника событий, то при открытии Event Viewer сообщит об ошибке. Поэтому хорошим тоном будет, не только зарегистрировать источник событий, но и предоставить файлы сообщений.

Рисунок 2.

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

Практика

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

Файл сообщений

Категории, сообщения и подставляемые параметры можно разместить как в одном файле, так и в разных. Для удобства и наглядности разместим всё в одном файле MYEVT_ENG.MC.

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

Категории событий – это всего лишь числовые идентификаторы, которые помогают фильтровать записи при просмотре журнала в Event Viewer. Каждый источник событий может обозначить свои категории любым числом. Надо только учесть, что они должны располагаться в начале файла сообщений последовательно (по порядку) и начинаться с 1. Подробное описание формата файла *.MC можно найти в в MSDN.

Идентификаторы событий

Каждый идентификатор события уникален в пределах файла сообщений. Каждый источник событий может определять свои собственные идентификаторы и связанные с ними строки. В Event Viewer при просмотре журнала мы как раз и видим эти строки (см. рисунок).

Формат кода идентификатора события выглядит так (впрочем, это соглашение, принятое в Windows):

3	3	2	2	2	2	2	2	2	2	2	2	1	1	1	1	1	1	1	1	1	1
7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
Severiry	C	R	Facility	Code

Важность ошибки (Severity):

Принадлежность (Customer bit):

Подробные пояснения можно найти в книге Рихтера или в MSDN.

Строки сообщений

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

Итак, мы написали файл MYEVT_ENG.MC. Теперь нам понадобится утилита MessageCompiler (MC.EXE), которая поставляется с MSVC6.0 и Platform SDK. Это консольное приложение скомпилирует файл сообщений:

В результате мы получим следующие файлы: MYEVT_ENG.H (определения символических имён), Msg00001.bin (бинарный ресурс для каждого языка), MYEVT_ENG.RC (в нём подключены бинарные ресурсы). Кстати, файл WINERROR.H, поставляемый с Microsoft Visual Studio, именно так и сгенерирован.

Теперь скомпилируем файл ресурсов MYEVT_ENG.RC:

В результате мы получим файл MYEVT_ENG.RES. И, наконец-то, скомпилируем библиотеку:

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

СОВЕТ

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

Регистрация источника событий

Для регистрации источника событий достаточно всего лишь определить несколько ключей в реестре (описание ключей приведены выше).

Теперь сервис Eventlog готов принимать сообщения о событиях, а Event Viewer – показывать их. Осталось только это использовать.

Использование журнала событий

Здесь стоит пояснить две важные функции: RegisterEventSource и ReportEvent.

lpSourceName – это имя источника события, который будет отсылать сообщения в журнал. В нашем примере это был MySuperApp. Нельзя использовать журнал Security (функция вернёт INVALID_HANDLE_VALUE). Если имя источника события не было найдено в реестре (в подключе \Eventlog), будет использоваться журнал Application.

Функция возвращает описатель журнала или NULL.

hEventLog – описатель, который вернула функция RegisterEventSource.

wType – тип события (EVENTLOG_SUCCESS, EVENTLOG_AUDIT_FAILURE, EVENTLOG_AUDIT_SUCCESS, EVENTLOG_ERROR_TYPE, EVENTLOG_WARNING_TYPE, EVENTLOG_INFORMATION). Указать можно только один тип.

wCategory – категория (см. Категории событий)

dwEventType – сообщение (см. Идентификаторы событий)

lpUserSid – указатель на структуру SID.

wNumStrings – количество подставляемых параметров в lpStrings. Каждая строка ограничена 32К.

dwDataSize – число байт в lpRawData.

lpRawData – произвольный массив байтов. Event Viewer никак не интерпретирует эти данные и отображает их в том виде, в котором они были переданы.

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

Послесловие

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

В Windows Vista Microsoft переработала этот сервис. Например, можно генерировать логи в XML, отсылать отчёты о логах и т.д.

Источник

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

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

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

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

Системный монитор (Sysmon)

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

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

Источник

event logging что это

Event Log

Принцип работы

Стоит ли включать опцию?

Журнал событий (Event Logging)

Win32: централизованное протоколирование событий

Автор: Серебряков Алексей (Smooky)
QUIBECK INC.
Источник: RSDN Magazine #3-2007

Опубликовано: 14.11.2007
Исправлено: 10.12.2016
Версия текста: 1.0

Предисловие

Теория

Рекомендации по протоколированию событий

События в журнале

Элементы журнала событий

Журналы

Источники событий

Практика

Файл сообщений

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

Идентификаторы событий

Строки сообщений

Регистрация источника событий

Использование журнала событий

Послесловие

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Журнал событий безопасности (Security Log)

Системный монитор (Sysmon)

Журналы Power Shell

Windows PowerShell log

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

event logging что это

Event Log

Принцип работы

Стоит ли включать опцию?

Журнал событий (Event Logging)

Win32: централизованное протоколирование событий

Автор: Серебряков Алексей (Smooky)QUIBECK INC. Источник: RSDN Magazine #3-2007

Опубликовано: 14.11.2007 Исправлено: 10.12.2016 Версия текста: 1.0

Предисловие

Теория

Рекомендации по протоколированию событий

События в журнале

Элементы журнала событий

Журналы

Источники событий

Практика

Файл сообщений

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

Идентификаторы событий

Строки сообщений

Регистрация источника событий

Использование журнала событий

Послесловие

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Журнал событий безопасности (Security Log)

Системный монитор (Sysmon)

Журналы Power Shell

Windows PowerShell log

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Автор: Серебряков Алексей (Smooky)
QUIBECK INC.
Источник: RSDN Magazine #3-2007

Опубликовано: 14.11.2007
Исправлено: 10.12.2016
Версия текста: 1.0