Журналирование 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 нужно добавить строку обработчика.
- authCommunity log,execute public
- format1 Trap from %B
- format2 Trap from %B
- traphandle default /usr/ local /etc/trapd.pl
Сам обработчик написан мной на perl, код можно взять по ссылке trapd.pl(Не рекомендуется копипастить подсвеченный код из поста, лучше взять по ссылке). Он разбирает входящие trap сообщения и формирует письмо администраторам.
s/(.*)\.(\d+)$/ $2 /g;<br/> print OUT «OID: $trap->
s/\n+/\n/g;<br/>my @data = split (/SNMPv2\-SMI\:\:enterprises\. 311 \. 1 \. 13 \. 1 \. 9999 \.\d+\. 0 \s/, $str );<br/>undef $error ;<br/>my $part = $data [ 1 ];<br/>my @str = split(/\n/, $part );<br/> $trap ->
s/\:$ //; <br/> $error = «Hostname: $trap->
/^(.*)\:\-/)<br/> <<br/>next;<br/> ><br/> else <br/> <<br/>push(@arrout, $line );<br/> ><br/>><br/> $error .= join ( «\n» ,@arrout);<br/> print OUT @data, «\n» ;<br/>&mail_send;<br/> <br/>close OUT;<br/> exit ( 0 );<br/> <br/>sub mail_send<br/> <<br/># my @arr = shift; <br/> use Net::SMTP;<br/> $smtp = Net::SMTP-> new ( ‘localhost’ );<br/> $smtp ->mail( ‘security@nagios.mydomain.ru’ );<br/> $smtp ->to( ‘account_admin@mydomain.ru’ );<br/> $smtp ->data();<br/> $smtp ->datasend( «To: account_admin\@mydomain.ru\n» );<br/> $smtp ->datasend( «Subject: $trap->
Hostname: bdc.mydoman.ru
Source: UDP: [192.168.0.3]:1081
Change Password Attempt:
Target Account Name:pupkin_v
Target Domain:MYDOM
Target Account ID:%
Caller User Name:pupkin_v
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x39B1BD)
Hostname: sadc.mydomain.ru
Source: UDP: [192.168.0.4]:1074
User Account Locked Out:
Target Account Name:ivanov_v
Target Account ID:%
Caller Machine Name:MX
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)
Hostname: sadc.mydomain.ru
Source: UDP: [192.168.0.4]:1072
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)
Многие из Вас, наверное, принимали участие в крупных и долгосрочных проектах, где разрабатывалось приличное количество модулей, использовались многочисленные библиотеки, сценарии и т.д. Мне тоже приходилось участвовать в таких проектах. Один из них и натолкнул меня на мысль о создании этой статьи. В том проекте участвовало множество программистов, разработчиков и тестеров. Каждый разработчик писал небольшой модуль протоколирования (логирования, от англ. logging, — снимать, записывать показания с прибора) и трассировки своих модулей и наработок. Кто-то писал свои утилиты, которые потом разбирали эти протоколы, кто-то использовал буферизованный вывод, т.е. какого-то чёткого регламента по этой деятельности не было. Результатом всей этой деятельности стало большое количество разбросанных текстовых и бинарных файлов с понятными и непонятными расширениями, непонятного формата и содержания. Понятно, что при такой организации так и должно было случиться. Хуже того, бывает и так, что при выходе финальной версии не удаётся всё это убрать, и всё это оказывается у пользователя и заказчика.
Для решения этой проблемы операционная система Windows предоставляет такой сервис и программный интерфейс, как Eventlog. Этот инструментарий относится к числу базовых сервисов Windows, т.е. поставляется с самой системой и система сама же его использует. Стоит заметить, что эта возможность есть только у систем семейств WinNT/XP, т.к. приложение для протоколирования событий является сервисом. Также стоит заметить, что в Windows Vista и Windows Longhorn этот сервис существенно переработан, новый вариант в этой статье рассматриваться не будет.
Мы не будем также рассматривать этот замечательный инструмент с точки зрения администраторов, сборщиков журналов и прочих персон, которые призваны управлять системой. Итак, приступим.
Теория
Рисунок 1.
Наверное, почти все разработчики используют в своих программах протоколирование событий при выявлении ошибок, отладке и диагностировании приложений. Но даже после успешного сбора и просмотра статистики иной раз бывает сложно проанализировать, что же всё-таки случилось и в каком месте? Так вот, сервис «Журнал событий» является стандартным, централизованным способом сбора статистики и просмотра сообщений о событиях, поступающих от приложений, сервисов операционной системы и аппаратных устройств. Средство для просмотра этих событий является оснасткой Microsoft Management Console. В Windows XP Rus эта оснастка запускается так: Пуск->Настройка->Панель управления->Администрирование->Просмотр Событий (Event Viewer).
| ПРЕДУПРЕЖДЕНИЕ
При использовании сервиса протоколирования в журнал следует записывать достаточно важные и нужные сведения о происшедших ошибках, которые действительно потом могут помочь разработчикам разобраться, что же произошло с приложением. Не следует, например, писать в системный журнал с периодичностью 100нс сообщения о том, что пользователь случайно удалил файл readme.txt. Журнал событий – это не средство трассировки. Рекомендации по протоколированию событийПри описании событий в журнале старайтесь придерживаться следующих рекомендаций, это поможет вам сделать журналы событий удобочитаемыми и опрятными. Помните, что журналы — это уже не только ваши собственные файлы трассировки, а разделяемый сервис, и не только вы ими пользуетесь. Сообщение в журнале событий – это, прежде всего, информация, способная помочь вам, администратору и даже пользователю понять, какая проблема возникла в приложении и как её устранить. В частности, это событие может предназначаться специалисту технической поддержки в вашей компании, и даже ему будет тоскливо читать сообщение: «Процесс А не смог прочитать 0x05 байт 0x2-ого сектора дисковода В». Поэтому идеальное сообщение должно помочь пользователю ответить на следующие вопросы:
Могут пригодиться и следующие рекомендации:
Соглашения о стиле содержания сообщения:
Это неполный список рекомендаций, взятый из MSDN. На самом деле в популярных книгах, например, у Саттера, есть более интересные рекомендации. События в журналеВ журнал можно записывать пять типов событий. Все типы событий достаточно понятно классифицированы, определены и могут включать много дополнительной информации. Каждое событий, которое мы посылаем из своего приложения, может иметь только один тип. Определены следующие типы событий:
Поскольку запись в журнал может происходить нечасто, в тексте сообщения следует достаточно полно описывать происшедшее событие. Следует достаточно понятно описывать событие, так как информацию о событии, до того как она попадёт к разработчику, может просмотреть, например, администратор системы и не придав ей особого значения, просто проигнорировать.
|
