Создание регулярного отчета по журналу событий Windows

Необходимость мониторинга журнала событий Windows не вызывает сомнений. На эту тему регулярно появляются статьи, в том числе и на Хабре. Однако, почему-то все примеры сводятся к мониторингу заранее определенных EventID. В своей утилите WinLogCheck я выбрал другой путь — получить отчет по EventLog, исключив события, которые регулярно появляются и не представляют для меня интереса.

Как оказалось, это не уникальный вариант, на таком же подходе основана утилита для Linux — logcheck. Но вполне возможно, что мое решение, все-таки, появилось чуть раньше.

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

Краткая история и кому может пригодится WinLogCheck

Это решение позволяет мне в настоящее время контролировать больше десятка Windows Server и помогает мне в работе с 1998 года. Первая версия была написана на ActiveState Perl для мониторинга трех серверов на Windows NT 4. Для Windows Server 2003 была написана оболочка для Logparser на JScript. Но с выходом Windows Server 2008 пришлось начать с нуля. Была попытка написать на Powershell, но, поскольку иногда я принимаю участие в разработке программ и немного знаю C#, для меня оказался удобным именно этот вариант.

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

Когда несколько лет назад в моем “подчинении” появились сервера под управлением Linux я узнал о существовании аналога своей утилиты — logcheck. Для тех кто не в курсе — утилита упоминается и рекомендуется во многих материалах по безопасности Linux и FreeBSD, например, в Debian Security Guide. После этого было принято решение сделать свою утилиту более удобной в использовании и опубликовать под именем WinLogCheck (первоначально она называлась UnknownEvents).

В результате утилита еще больше стала похожа logcheck — у меня она запускается в 9:00 на каждом сервере и через 5-10 минут в моем почтовом ящике больше десятка сообщений с отчетами. Обычно мне достаточно пары минут, чтобы просмотреть все.

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

Как работает Winlogcheck

Алгоритм основного режима работы:

1. Получить список зарегистрированных журналов событий. Для обычного Windows Server 2008 — 7, для сервера с Active Directory — 10.
2. Для каждого журнала событий формируется запрос — получить список событий за последние сутки (приблизительно), исключая события, указанные в файле исключений “\path\to\winlogcheck\exclude\<eventlog_name>.conf
3. Из полученного списка формируется отчет в HTML, который пишется во временный файл (на тот случай, если письмо с отчетом не дойдет).
4. Отчет отправляется по почте.

Несмотря на то, что в .NET есть свои методы для получения списка событий, я использую WMI (подробнее WMI Tasks: Event Logs). Так проще работать с тестом сообщения. Единственный минус — задержка при выполнении запросов при большом количестве записей в журнале. Например, на одном из контролеров домена создание отчета занимает 5-6 минут.

Вначале рабочего дня по каждому серверу я получаю примерно такой отчет (это отчет с реально работающего Windows Server 2008 R2 with Hyper-V):



Все в порядке, разовая ошибка в DNS-Client не требует особого внимания. Обратите внимание на Subject сообщения — чаще всего письма даже не требуется открывать: обычно тема заканчивается фразой “errors=0, warnings=0, other=0”.

Как использовать WinLogCheck

Параметры командной строки

Утилита запускается из командной строки с правами администратора.
Обязательный параметр — режим работы: EXCLUDE или INCLUDE. Запуск в основном EXCLUDE-режиме:

winlogcheck -m exclude

Два опциональных параметра предусмотрены для INCLUDE-режима (для себя я его называю режим спецотчетов):

-l <eventlog_name> — для указания журнала по которому надо получить отчет
-f — имя фильтра в файле “\path\to\winlogcheck\include\<eventlog_name>.conf

Например, для отдельного отчета по успешным подключениям к RAS серверу на этом сервере у меня есть файл “\path\to\winlogcheck\include\system.conf” с таким текстом (о формате файла с фильтром — ниже):

[General]
RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272

Запускается тоже раз в день:

winlogcheck -m include -l system -f RASconnects

Естественно, такой же фильтр есть и для режима EXCUDE — чтобы в общем отчете по серверу эти записи отсутствовали. Один из отчетов:



В режиме EXCLUDE опциональные параметры использую только для тестирования.

Параметры программы

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

[General]

## Глубина запроса (в часах). 
## По умолчанию: за 24 часа (за последние сутки)
##
#TimePeriod = 24

## Каталог для записи отчетов
## По умолчанию: 'path\to\winlogcheck\reports\' 
## Если вы не хотите получать отчеты по почте, можете записывать
## их в каталог, доступный на внутреннем веб-сервере.
## Когда-то я использовал такой вариант.
##
#ReportPath = c:\inetpub\wwwroot\winlogcheckreports

## CSS оформление для отчета.
## В одну строку!
##
ReportCSS = h1 {margin:0;font-weight:400} .servername, .subhead {font-weight:700} table {width:100%;} td {padding:0.25em} th {border:1px 0} tr:nth-child(odd) td {padding-bottom:1.5em, border-bottom:1px} tr:nth-child(even) {background-color:rgb(248,248,248)} caption {font-size:120%;text-align:left;padding:10px;background:rgb(216,216,216)} .error, .failure {background:rgb(255,127,127)} .warning {background:rgb(255,233,127)}

## Настройка почты
## Если закомментировано - отчеты не посылаются.
## Я использую свой почтовый сервер, поэтому
## аутентификация не поддерживается.
##
#[Mail]
#SMTP_Server = localhost
#Mail_From = Winlogcheck SERVERNAME <administrator@example.com>
#Mail_To = Administrator SERVERNAME <administrator@example.com>

Мониторинг работы самой утилиты

В разработках нашей компании используется NLog, поэтому я не стал изобретать велосипед. Во включенном в пакет конфигурационном файле для NLog настроены вывод журнала выполнения на консоль и в файл “\path\to\winlogcheck\logs\winlogcheck.log” с ротацией (каждый день новый файл, срок хранения — 10 дней).

Настройка фильтров

Переходим к самому интересному. Типичный экран Event Viewer на сервере с установленным IIS:



Наверное всем знакомы события:

• «Winlogon»: ID 7001 или 7002 — «User Logon/Logoff Notification for Customer Experience Improvement Program»
• «Service Control Manager»: ID 7036 или 7040 с сообщениями: «The WinHTTP Web Proxy Auto-Discovery Service service entered the running/stopped state» или «The start type of the WinHTTP Web Proxy Auto-Discovery service was changed from… to… „

С ними все ясно — нам в отчете они не нужны.

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

1. Имя журнала событий. В данном случае “System”, значит фильтр запишем в файл “\path\to\winlogcheck\exclude\system.conf”.
2. Уровень — EventType (integer). В самом журнале определяется числами:
   
   • 1 — Error
   • 2 — Warning
   • 3 — Information
   • 4 — Success
   • 5 — Failure
   
   
3. Идентификатор события — Eventcode (integer)
4. Категория — CategoryString (string)
5. Источник — SourceName (string)

А то, что мы видим в описании события, находится в поле Message.

Таким образом, чтобы исключить из отчета указанные выше события, необходимо сформировать файл “\path\to\winlogcheck\exclude\system.conf” с текстом:

[General]

UserNotify : SourceName = 'Microsoft-Windows-Winlogon' AND ( EventCode = 7001 OR EventCode = 7002 )

WinHTTP : SourceName = 'Service Control Manager' AND (EventCode = 7036 OR EventCode = 7040) AND Message LIKE '%WinHTTP%'

Комментарии к формату файла с фильтрами

• Первоначально в файлах с фильтрами использовались встроенные в язык типы данных, например в версии на JScript — объект Dictonary. Потом пробовал JSON. Но во всех случаях легко допустить ошибку, поэтому был выбран формат ini-файлов.
• Имя фильтра обязательно, но в настоящее время используется только в INCLUDE-режиме при построении специальных отчетов.
• Строка условия — вопросов вызывать не должна.
• Как вы могли заметить — все примеры для английской версии Windows Server. Тем не менее все прекрасно работает и на русской версии. Для этого необходимо, чтобы файлы фильтров были в UTF-8. Значение полей SourceName и CategoryString переводятся в самом Event Viewer, поэтому в запросах необходимо использовать английские аналоги, а вот текст сообщения — на русском. Возможно, в следующее обновление программы включу пример для русской версии Windows Server.

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

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

Последние замечания

• На Codeplex опубликованы архив с программой и исходные коды программы под лицензией LGPL (особо не разбирался). Поскольку я не являюсь профессиональным программистом — кодом не хвастаюсь.
• Утилита была написана специально для WIndows Server 2008, однако работает и на единственном доступном Windows Server 2003. На новой версии WIndows Server 2012 еще не проверял, но проблем быть не должно. Также должна работать на Windows XP / Vista / 7 / 8.
• Описание и краткая инструкция для Codeplex были подготовлены с помощью Google Translate. Готовый перевод был проверен знающими и признан похожим на настоящий английский.:-). Если у кого есть опыт переводов технической документации — буду рад услышать замечания и предложения.

Очень часто поднимается вопрос о мониторинге Active Directory. Мое решение вполне можно использовать для решения этой задачи. Однако, я уже давно не занимаюсь управлением “большими» доменами, поэтому вымышленных примеров для мониторинга событий AD придумывать не стал.

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