Журналирование Windows EventLog и система оповещения для администраторов
Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.
Microsoft своими «добрыми» технологиями сделала Windows практически несовместимым со штатными системами журналирования событий(syslog), но оставила небольшую лазейку которую можно использовать. Лазейка представляет собой комбинацию SNMP trap и программы экспорта системных событий evntwin.
Для работы связки нужен настроенный snmptrapd, а также активированный сервис SNMP на windows сервере (добавляется через «добавление/удаление компонентов»).
Первым делом нужно настроить сервер на который будут сбрасываться сообщения из Eventlog. После того как сервис настроен, запускаем программу evntwin.exe technet.microsoft.com/en-us/library/cc759390%28WS.10%29.aspx Как она выглядит видно на следующем скриншоте.
Принцип использования evntwin прост. Вы выбираете категорию и код события которые Вас интересуют и добавляете их в список. При наступлении события сообщение одновременно будет сохранено в EventLog, а также будет «трапнуто» на сервер мониторинга.
На сервере мониторинга в snmptrapd.conf нужно добавить строку обработчика.
Сам обработчик написан мной на perl, код можно взять по ссылке trapd.pl(Не рекомендуется копипастить подсвеченный код из поста, лучше взять по ссылке). Он разбирает входящие trap сообщения и формирует письмо администраторам.
Logon Failure: Reason:Unknown user name or bad password User Name:Popov_V Domain:MYDOM Logon Type:3 Logon Process:Advapi Authentication Package:Negotiate Workstation Name:SADC Caller User Name:SADC$ Caller Domain:MYDOM Caller Logon ID:(0x0,0x3E7) Caller Process ID:580 Source Network Address:192.168.0.20 Source Port:36018
Так как мы подписаны только на интересующие нас сообщения, мы не видим остального системного мусора из EventLog. Очень удобна данная система при вирусных эпидемиях типа Kido, когда сразу нельзя понять откуда пошло всё размножаться или при брутфорсе системных паролей. Потому что чётко виден Logon Failure и имя машины с которой была неудачная попытка.
Спокойной Вам работы. PS: готовый конфиг с представленными на скриншоте категориями лежит тут
Журнал событий (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. Журнал событий – это не средство трассировки.
Рекомендации по протоколированию событий
Сообщение в журнале событий – это, прежде всего, информация, способная помочь вам, администратору и даже пользователю понять, какая проблема возникла в приложении и как её устранить. В частности, это событие может предназначаться специалисту технической поддержки в вашей компании, и даже ему будет тоскливо читать сообщение: «Процесс А не смог прочитать 0x05 байт 0x2-ого сектора дисковода В». Поэтому идеальное сообщение должно помочь пользователю ответить на следующие вопросы:
Могут пригодиться и следующие рекомендации:
Соглашения о стиле содержания сообщения:
Это неполный список рекомендаций, взятый из MSDN. На самом деле в популярных книгах, например, у Саттера, есть более интересные рекомендации.
События в журнале
В журнал можно записывать пять типов событий. Все типы событий достаточно понятно классифицированы, определены и могут включать много дополнительной информации. Каждое событий, которое мы посылаем из своего приложения, может иметь только один тип. Определены следующие типы событий:
Тип события
Пояснение
Ошибка (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, отсылать отчёты о логах и т.д.
Что такое eventlog.exe? Это безопасно или вирус? Как удалить или исправить это
Что такое eventlog.exe?
eventlog.exe это исполняемый файл, который является частью Windows NT Server разработанный Microsoft, Версия программного обеспечения для Windows NT 3.1 NT 3.1: 1.0.0.0 обычно 77188 в байтах, но у вас может отличаться версия.
Является ли eventlog.exe безопасным, или это вирус или вредоносная программа?
Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, в случае с Eventlog.exe его путь будет примерно таким: C: \ Program Files \ Microsoft \ Windows NT Server \ eventlog.exe.
Если статус процесса «Проверенная подписывающая сторона» указан как «Невозможно проверить», вам следует взглянуть на процесс. Не все хорошие процессы Windows имеют метку проверенной подписи, но ни один из плохих.
Самые важные факты о eventlog.exe:
Если у вас возникли какие-либо трудности с этим исполняемым файлом, вы должны определить, заслуживает ли он доверия, перед удалением eventlog.exe. Для этого найдите этот процесс в диспетчере задач.
Найти его местоположение и сравнить размер и т. Д. С приведенными выше фактами
Если вы подозреваете, что можете быть заражены вирусом, вы должны немедленно попытаться это исправить. Чтобы удалить вирус eventlog.exe, необходимо скачайте и установите приложение полной безопасности, как это, Обратите внимание, что не все инструменты могут обнаружить все типы вредоносных программ, поэтому вам может потребоваться попробовать несколько вариантов, прежде чем вы добьетесь успеха.
Могу ли я удалить или удалить eventlog.exe?
Не следует удалять безопасный исполняемый файл без уважительной причины, так как это может повлиять на производительность любых связанных программ, использующих этот файл. Не забывайте регулярно обновлять программное обеспечение и программы, чтобы избежать будущих проблем, вызванных поврежденными файлами. Что касается проблем с функциональностью программного обеспечения, проверяйте обновления драйверов и программного обеспечения чаще, чтобы избежать или вообще не возникало таких проблем.
Однако, если это не вирус и вам нужно удалить eventlog.exe, вы можете удалить Windows NT Server с вашего компьютера, используя его деинсталлятор. Если вы не можете найти его деинсталлятор, то вам может потребоваться удалить Windows NT Server, чтобы полностью удалить eventlog.exe. Вы можете использовать функцию «Установка и удаление программ» на панели управления Windows.
Распространенные сообщения об ошибках в eventlog.exe
Наиболее распространенные ошибки eventlog.exe, которые могут возникнуть:
Как исправить eventlog.exe
Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.
Чтобы помочь вам проанализировать процесс eventlog.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.
Обновлен декабрь 2021:
Мы рекомендуем вам попробовать этот новый инструмент. Он исправляет множество компьютерных ошибок, а также защищает от таких вещей, как потеря файлов, вредоносное ПО, сбои оборудования и оптимизирует ваш компьютер для максимальной производительности. Это исправило наш компьютер быстрее, чем делать это вручную:
Загрузите или переустановите eventlog.exe
Вход в музей Мадам Тюссо не рекомендуется загружать замещающие exe-файлы с любых сайтов загрузки, так как они могут сами содержать вирусы и т. д. Если вам нужно скачать или переустановить eventlog.exe, мы рекомендуем переустановить основное приложение, связанное с ним. Windows NT Server.
Технические особенности Windows NT
Информация об операционной системе
Ошибки eventlog.exe могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:
