- PVSM.RU - https://www.pvsm.ru -
Необходимость мониторинга журнала событий Windows не вызывает сомнений. На эту тему регулярно появляются статьи, в том числе и на Хабре. Однако, почему-то все примеры сводятся к мониторингу заранее определенных EventID. В своей утилите WinLogCheck я выбрал другой путь — получить отчет по EventLog, исключив события, которые регулярно появляются и не представляют для меня интереса.
Как оказалось, это не уникальный вариант, на таком же подходе основана утилита для Linux — logcheck [1]. Но вполне возможно, что мое решение, все-таки, появилось чуть раньше.
В этой статье я постараюсь обойтись без технических подробностей. Немного об истории создания — по-моему, это позволит понять, почему и в каких условиях появилась эта утилита и где-когда ее лучше использовать. Далее краткое описание алгоритма работы и что-то похожее на инструкцию по применению.
Это решение позволяет мне в настоящее время контролировать больше десятка 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 минут в моем почтовом ящике больше десятка сообщений с отчетами. Обычно мне достаточно пары минут, чтобы просмотреть все.
Я несколько раз пытался найти готовый инструмент мониторинга, но ничего удобного, простого и практичного так и не встретил. Возможно, все дело в привычке. Тем не менее, если у вас не очень большое количество серверов — попробуйте, возможно, вам понравится мой вариант.
Алгоритм основного режима работы:
Несмотря на то, что в .NET есть свои методы для получения списка событий, я использую WMI (подробнее WMI Tasks: Event Logs [2]). Так проще работать с тестом сообщения. Единственный минус — задержка при выполнении запросов при большом количестве записей в журнале. Например, на одном из контролеров домена создание отчета занимает 5-6 минут.
Вначале рабочего дня по каждому серверу я получаю примерно такой отчет (это отчет с реально работающего Windows Server 2008 R2 with Hyper-V):
Все в порядке, разовая ошибка в DNS-Client не требует особого внимания. Обратите внимание на Subject сообщения — чаще всего письма даже не требуется открывать: обычно тема заканчивается фразой “errors=0, warnings=0, other=0”.
Утилита запускается из командной строки с правами администратора.
Обязательный параметр — режим работы: EXCLUDE или INCLUDE. Запуск в основном EXCLUDE-режиме:
winlogcheck -m exclude
Два опциональных параметра предусмотрены для INCLUDE-режима (для себя я его называю режим спецотчетов):
-l <eventlog_name> — для указания журнала по которому надо получить отчет
-f — имя фильтра в файле “pathtowinlogcheckinclude<eventlog_name>.conf
Например, для отдельного отчета по успешным подключениям к RAS серверу на этом сервере у меня есть файл “pathtowinlogcheckincludesystem.conf” с таким текстом (о формате файла с фильтром — ниже):
[General]
RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272
Запускается тоже раз в день:
winlogcheck -m include -l system -f RASconnects
Естественно, такой же фильтр есть и для режима EXCUDE — чтобы в общем отчете по серверу эти записи отсутствовали. Один из отчетов:
В режиме EXCLUDE опциональные параметры использую только для тестирования.
Параметры хранятся в конфигурационном файле winlogcheck.ini. Файл небольшой, поэтому привожу полностью с дополнительными комментариями:
[General]
## Глубина запроса (в часах).
## По умолчанию: за 24 часа (за последние сутки)
##
#TimePeriod = 24
## Каталог для записи отчетов
## По умолчанию: 'pathtowinlogcheckreports'
## Если вы не хотите получать отчеты по почте, можете записывать
## их в каталог, доступный на внутреннем веб-сервере.
## Когда-то я использовал такой вариант.
##
#ReportPath = c:inetpubwwwrootwinlogcheckreports
## 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 настроены вывод журнала выполнения на консоль и в файл “pathtowinlogchecklogswinlogcheck.log” с ротацией (каждый день новый файл, срок хранения — 10 дней).
Переходим к самому интересному. Типичный экран Event Viewer на сервере с установленным IIS:
Наверное всем знакомы события:
С ними все ясно — нам в отчете они не нужны.
Фильтры записываются с использованием SQL синтаксиса, названия полей в журнале событий отличаются от того, что мы видим на экране. Для составления фильтра мы можем использовать:
А то, что мы видим в описании события, находится в поле Message.
Таким образом, чтобы исключить из отчета указанные выше события, необходимо сформировать файл “pathtowinlogcheckexcludesystem.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%'
Комментарии к формату файла с фильтрами
Основные фильтры, которые я использую в своей работе, включены в архив с утилитой.
Особое отношение только к журналу безопасности — очень часто в нем очень много событий, поэтому действует фильтр по умолчанию: в отчет попадают только ошибки.
Очень часто поднимается вопрос о мониторинге Active Directory. Мое решение вполне можно использовать для решения этой задачи. Однако, я уже давно не занимаюсь управлением “большими» доменами, поэтому вымышленных примеров для мониторинга событий AD придумывать не стал.
Это решение не претендует на универсальность, но, на мой взгляд, вполне может пригодится в любой сети с небольшим количеством серверов под управлением Windows.
Автор: nelsh
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/19334
Ссылки в тексте:
[1] logcheck: http://logcheck.org/
[2] WMI Tasks: Event Logs: http://msdn.microsoft.com/en-us/library/windows/desktop/aa394593(v=vs.85).aspx
[3] Источник: http://habrahabr.ru/post/156937/
Нажмите здесь для печати.