Zabbix мониторинг журнала событий windows — Ваш верный помощник с OS Windows

Время на прочтение9 мин

Количество просмотров174K

Некоторое время поработав с Zabbix, я подумал, почему бы не попробовать использовать его в качестве решения для мониторинга событий информационной безопасности. Как известно, в ИТ инфраструктуре предприятия множество самых разных систем, генерирующих такой поток событий информационной безопасности, что просмотреть их все просто невозможно. Сейчас в нашей корпоративной системе мониторинга сотни сервисов, которые мы наблюдаем с большой степенью детализации. В данной статье, я рассматриваю особенности использования Zabbix в качестве решения по мониторингу событий ИБ.

Что же позволяет Zabbix для решения нашей задачи? Примерно следующее:

Максимальная автоматизация процессов инвентаризации ресурсов, управления уязвимостями, контроля соответствия политикам безопасности и изменений.
Постоянная защита корпоративных ресурсов с помощью автоматического мониторинга информационной безопасности.
Возможность получать максимально достоверную картину защищенности сети.
Анализ широкого спектра сложных систем: сетевое оборудование, такое как Cisco, Juniper, платформы Windows, Linux, Unix, СУБД MSQL, Oracle, MySQL и т.д., сетевые приложения и веб-службы.
Минимизация затрат на аудит и контроль защищенности.

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

Подготовка

Итак, для начала я установил сервер мониторинга Zabbix. В качестве платформы мы будем использовать ОС FreeBSD. Думаю, что рассказывать в деталях о процессе установки и настройки нет необходимости, довольно подробная документация на русском языке есть на сайте разработчика, начиная от процесса установки до описания всех возможностей системы.
Мы будем считать что сервер установлен, настроен, а так же настроен web-frontend для работы с ним. На момент написания статьи система работает под управлением ОС FreeBSD 9.1, Zabbix 2.2.1.

Мониторинг событий безопасности MS Windows Server

С помощью системы мониторинга Zabbix можно собирать любую имеющуюся информацию из системных журналов Windows с произвольной степенью детализации. Это означает, что если Windows записывает какое-либо событие в журнал, Zabbix «видит» его, например по Event ID, текстовой, либо бинарной маске. Кроме того, используя Zabbix, мы можем видеть и собирать колоссальное количество интересных для мониторинга безопасности событий, например: запущенные процессы, открытые соединения, загруженные в ядро драйверы, используемые dll, залогиненных через консоль или удалённый доступ пользователей и многое другое.

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

Устанавливая решение по мониторингу событий ИБ в ИТ инфраструктуре следует учитывать необходимость выбора баланса между желанием отслеживать всё подряд, и возможностями по обработке огромного количества информации по событиям ИБ. Здесь Zabbix открывает большие возможности для выбора. Ключевые модули Zabbix написаны на C/C++, скорость записи из сети и обработки отслеживаемых событий составляет 10 тысяч новых значений в секунду на более менее обычном сервере с правильно настроенной СУБД.

Всё это даёт нам возможность отслеживать наиболее важные события безопасности на наблюдаемом узле сети под управлением ОС Windows.

Итак, для начала рассмотрим таблицу с Event ID, которые, на мой взгляд, очевидно, можно использовать для мониторинга событий ИБ:

События ИБ MS Windows Server Security Log

Я уделяю внимание локальным группам безопасности, но в более сложных схемах AD необходимо учитывать так же общие и глобальные группы.
Дабы не дублировать информацию, подробнее о критически важных событиях можно почитать в статье:
http://habrahabr.ru/company/netwrix/blog/148501/

Способы мониторинга событий ИБ MS Windows Server

Рассмотрим практическое применение данной задачи.
Для сбора данных необходимо создать новый элемент данных:

Ключ: eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781]
Тип элемента данных: Zabbix агент (активный)
Тип информации: Журнал (лог)

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

Хочу заметить что в данном ключе в качестве имени мы используем журнал событий Security.
Теперь, когда элемент данных мы получили, следует настроить триггер. Триггер – это механизм Zabbix, позволяющий сигнализировать о том, что наступило какое-либо из отслеживаемых событий. В нашем случае – это событие из журнала сервера или рабочей станции MS Windows.

Теперь все что будет фиксировать журнал аудита с указанными Event ID будет передано на сервер мониторинга. Указание конкретных Event ID полезно тем, что мы получаем только необходимую информацию, и ничего лишнего.

Вот одно из выражений триггера:

{Template Windows - Eventlog 2008:eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781].logeventid(4624)}=1&{Template Windows - Eventlog 2008:eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781].nodata(5m)}=0

Данное выражение позволит отображать на Dashboard информацию о том что «Вход с учётной записью выполнен успешно», что соответствует Event ID 4624 для MS Windows Server 2008. Событие исчезнет спустя 5 минут, если в течение этого времени не был произведен повторный вход.

Если же необходимо отслеживать определенного пользователя, например “Администратор”, можно добавить к выражению триггера проверку по regexp:

&{Template Windows - Eventlog 2008:eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781,,skip].regexp(Администратор)}=1

Тогда триггер сработает только в том случае если будет осуществлён вход в систему именно под учетной записью с именем “Администратор”.

P.S.

Мы рассматривали простейший пример, но так же можно использовать более сложные конструкции. Например с использованием типов входа в систему, кодов ошибок, регулярных выражений и других параметров.

Таким образом тонны сообщений, генерируемых системами Windows будет проверять Zabbix, а не наши глаза. Нам остаётся только смотреть на панель Zabbix Dashboard.
Дополнительно, у меня настроена отправка уведомлений на e-mail. Это позволяет оперативно реагировать на события, и не пропустить события произошедшие например в нерабочее время.

Мониторинг событий безопасности Unix систем

Система мониторинга Zabbix так же позволяет собирать информацию из лог-файлов ОС семейства Unix.

События ИБ в Unix системах, подходящие для всех

Такими проблемами безопасности систем семейства Unix являются всё те же попытки подбора паролей к учётным записям, а так же поиск уязвимостей в средствах аутентификации, например, таких как SSH, FTP и прочих.

Некоторые критически важные события в Unix системах

Исходя из вышеуказанного следует, что нам необходимо отслеживать действия, связанные с добавлением, изменением и удалением учётных записей пользователей в системе.
Так же немаловажным фактом будет отслеживание попыток входа в систему. Изменения ключевых файлов типа sudoers, passwd, etc/rc.conf, содержимое каталогов /usr/local/etc/rc.d наличие запущенных процессов и т.п.

Способы мониторинга ИБ в Unix системах

Рассмотрим следующий пример. Нужно отслеживать входы в систему, неудачные попытки входа, попытки подбора паролей в системе FreeBSD по протоколу SSH.

Вся информация об этом, содержится в лог-файле /var/log/auth.log.
По умолчанию права на данный файл — 600, и его можно просматривать только с привилегиями root. Придется немного пожертвовать локальной политикой безопасности, и разрешить читать данный файл группе пользователей zabbix:
Меняем права на файл:

chgrp zabbix /var/log/auth.log
chmod 640 /var/log/auth.log

Нам понадобится новый элемент данных со следующим ключом:

log[/var/log/auth.log,sshd,,,skip]

Все строки в файле /var/log/auth.log содержащие слово ”sshd” будут переданы агентом на сервер мониторинга.

Далее можно настроить триггер со следующим выражением:

{Template FreeBSD - SSH:log[/var/log/auth.log,sshd,,,skip].regexp(error:)}|{Template FreeBSD - SSH:log[/var/log/auth.log,sshd,,,skip].regexp(Wrong passwordr:)}&{Template FreeBSD - SSH:log[/var/log/auth.log,sshd,,,skip].nodata(3m)}=0

Это выражение определяется как проблема, когда в лог-файле появляются записи, отобранные по регулярному выражению “error:”. Открыв историю полученных данных, мы увидим ошибки, которые возникали при авторизации по протоколу SSH.

Вот пример последнего значения элемента данных, по которому срабатывает данный триггер:

Рассмотрим ещё один пример мониторинга безопасности в ОС FreeBSD:
С помощью агента Zabbix мы можем осуществлять проверку контрольной суммы файла /etc/passwd.
Ключ в данном случае будет следующий:

vfs.file.cksum[/etc/passwd]

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

Например, если мы хотим получать список пользователей, которые на данный момент заведены в системе, можно использовать такой пользовательский параметр:

UserParameter=system.users.list, /bin/cat /etc/passwd | grep -v "#" | awk -F\: '{print $$1}'

И, например, настроить триггер на изменение в получаемом списке.

Или же можно использовать такой простой параметр:

UserParameter=system.users.online, /usr/bin/users

Так мы увидим на Dashboard, кто на данный момент находится в системе:

Мониторинг событий ИБ на сетевых устройствах

С помощью Zabbix можно так же очень эффективно отслеживать события ИБ на сетевых устройствах Cisco и Juniper, используя протокол SNMP. Передача данных с устройств осуществляется с помощью так называемых трапов (SNMP Trap).

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

Способы мониторинга

Рассмотрим опять же пример с авторизацией:
В качестве стенда я буду использовать эмулятор GNS3 с маршрутизатором Cisco 3745. Думаю многим знакома данная схема.

Для начала нам необходимо настроить отправку SNMP трапов с маршрутизатора на сервер мониторинга. В моём случае это будет выглядеть так:

login block-for 30 attempts 3 within 60
login on-failure log
login on-success log
login delay 5

logging history 5

snmp-server enable traps syslog
snmp-server enable traps snmp authentication
snmp-server host 192.168.1.1 public

Будем отправлять события из Syslog и трапы аутентификации. Замечу, что удачные и неудачные попытки авторизации пишутся именно в Syslog.

Далее необходимо настроить прием нужных нам SNMP трапов на сервере мониторинга.
Добавляем следующие строки в snmptt.conf:

EVENT clogMessageGenerated .1.3.6.1.4.1.9.9.41.2.0.1 "Status Events" Normal
FORMAT ZBXTRAP $ar $N $*
SDESC
EDESC

В нашем примере будем ловить трапы Syslog.

Теперь необходимо настроить элемент данных для сбора статистики со следующим ключом:

snmptrap[“Status”]

Если трап не настроен на сервере мониторинга, то в логе сервера будут примерно такие записи:

unmatched trap received from [192.168.1.14]:...

В результате в полученном логе будет отражаться информация о попытках входа с детализированной информацией (user, source, localport и reason в случае неудачи):

Ну и можно настроить триггер для отображения события на Dashboard:

{192.168.1.14:snmptrap["Status"].regexp(LOGIN_FAILED)}&{192.168.1.14:snmptrap["Status"].nodata(3m)}=0

В сочетании с предыдущим пунктом у нас на Dashboard будет информация вот такого плана:

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

Хочу заметить что приведённый пример не будет работать на продуктах Cisco ASA и PIX, так как там несколько иначе организована работа с логированием авторизации.

Juniper и Syslog

Ещё одним примером мы разберем мониторинг авторизации в JunOS 12.1 для устройств Juniper.
Тут мы не сможем воспользоваться трапами SNMP, потому как нет поддержки отправки трапов из Syslog сообщений. Нам понадобится Syslog сервер на базе Unix, в нашем случае им будет тот же сервер мониторинга.

На маршрутизаторе нам необходимо настроить отправку Syslog на сервер хранения:

system syslog host 192.168.1.1 authorization info

Теперь все сообщения об авторизации будут отправляться на Syslog сервер, можно конечно отправлять все сообщения (any any), но переизбыток информации нам не нужен, отправляем только необходимое.

Далее переходим к Syslog серверу
Смотрим tcpdump, приходят ли сообщения:

tcpdump -n -i em0 host 192.168.1.112 and port 514
12:22:27.437735 IP 192.168.1.112.514 > 192.168.1.1.514: SYSLOG auth.info, length: 106

По умолчанию в настройках syslog.conf все что приходит с auth.info должно записываться в /var/log/auth.log. Далее делаем все аналогично примеру с мониторингом входов в Unix.

Вот пример строки из лога:

Остается только настроить триггер на данное событие так же как это было рассмотрено в примере с авторизацией на Unix сервере.

P.S.

Таким способом можно отслеживать множество событий, среди которых такие как: сохранение конфигурации устройства (commit), вход и выход из режима редактирования конфигурации (edit).
Так же хочу заметить, что аналогичным способом можно осуществлять мониторинг и на устройствах Cisco, но способ с SNMP трапами мне кажется более быстрым и удобным, и исключается необходимость в промежуточном Syslog сервере.

Заключение

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

Источник

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

Шаблон или прототип элемента мониторинга будет выглядеть следующим образом (параметры для удобства пронумерованы):

eventlog[1- имя журнала,2-регулярное выражение,3-важность,4-источник,5-eventid,6-макс кол-во строк, 7-режим]

Тип данных: журнал (лог)

Далее рассмотрим конкретные практические примеры.

1. Ошибки в журнале приложений.

Максимально простой пример сбора ошибок в журнале «Приложение» (события уровня «Ошибка»)

eventlog[Application,,"Error",,,,skip]

2. Ошибки отложенной записи.

eventlog[System,,"Warning",,50,,skip]

краткие пояснения:

System — журнал система

Warning — тип события: предупреждение

50 — id события равно 50

skip — берем только свежие значения (не перечитываем весь лог)

триггер:

count(/Terminal server/eventlog[System,,"Warning",,50,,skip],30m)>7 and nodata(/Terminal server/eventlog[System,,"Warning",,50,,skip],60m)<>1

где Terminal server — это просто имя шаблона, в котором используются элемент данных и триггер

3. Ошибки диска.

eventlog[System,,"Warning",,153,,skip]

триггер:

count(/Template OS Windows by Zabbix agent active/eventlog[System,,"Warning",,153,,skip],30m)>5 and nodata(/Template OS Windows by Zabbix agent active/eventlog[System,,"Warning",,153,,skip],60m)<>1

4. ошибки в журнале событий от службы MSSQLSERVER.

eventlog[Application,,"Error","MSSQLSERVER",,,skip]

триггер:

count(/Template OS Windows SQL for 1C/eventlog[Application,,"Error","MSSQLSERVER",,,skip],8m)>0 and nodata(/Template OS Windows SQL for 1C/eventlog[Application,,"Error","MSSQLSERVER",,,skip],10m)<>1

Полезные ссылки:

https://www.zabbix.com/documentation/5.0/ru/manual/config/items/itemtypes/zabbix_agent/win_keys

Источник

Zabbix – Monitor Event Log on Windows

Hardware List:

The following section presents the list of equipment used to create this Zabbix tutorial.

Every piece of hardware listed above can be found at Amazon website.

Zabbix Playlist:

On this page, we offer quick access to a list of videos related to Zabbix installation.

Don’t forget to subscribe to our youtube channel named FKIT.

Zabbix Related Tutorial:

On this page, we offer quick access to a list of tutorials related to Zabbix installation.

Zabbix Agent Configuration Required

First, the Zabbix agent installed on the Windows computer must be configured in Active mode.

Here is an example of a Zabbix agent configuration file in Passive mode: zabbix_agentd.conf

Here is an example of a Zabbix agent configuration file in Active mode: zabbix_agentd.conf

You have finished the required part of the configuration.

Tutorial – Zabbix Monitor Windows Log File

Now, we need to access the Zabbix server dashboard and add the Windows computer as a Host.

Open your browser and enter the IP address of your web server plus /zabbix.

In our example, the following URL was entered in the Browser:

• http://35.162.85.57/zabbix

On the login screen, use the default username and default password.

• Default Username: Admin
• Default Password: zabbix

After a successful login, you will be sent to the Zabbix Dashboard.

On the dashboard screen, access the Configuration menu and select the Host option.

On the top right of the screen, click on the Create host button.

On the Host configuration screen, you will have to enter the following information:

• Host Name – Enter a Hostname to monitor.
• Visible Hostname – Repeat the hostname.
• New group – Enter a name to identify a group of similar devices.
• Agent Interface – Enter the IP address of the Hostname.

Here is the original image, before our configuration.

Here is the new image with our configuration.

Click on the Add button to include this host on the Zabbix database.

On the dashboard screen, access the Configuration menu and select the Host option.

Locate and click on the hostname that you created before.

In our example, we selected the hostname: WINDOWS-SERVER-01

On the Host properties screen, access the Applications tab.

On the top right part of the screen, click on the Create application button.

On the Host applications screen, create a new application named: LOG

After finishing the Application creation, access the Items tab.

On the top right part of the screen, click on the Create item button.

On the Item creation screen, you need to configure the following items:

• Name: Enter an identification like: Windows System Log

• Type: Zabbix Agent (Active)

• Key: eventlog[System,,,,,,skip]

• Type of Information: Log

• Update interval: 1 Second

• Application: LOG

Click on the Add button to finish the Item creation and wait 5 minutes.

In order to test your configuration, access the Monitoring menu and click on the Latest data option.

Use the filter configuration to select the desired hostname and click on the Apply button.

In our example, we selected the hostname WINDOWS-SERVER-01.

You should be able to see the results of your Windows log file monitoring using Zabbix.

Click on the History option to see more Windows event log details.

In our example, we are monitoring the Windows System Event log.

Congratulations! You have configured the Zabbix Event log monitoring feature on Windows.

VirtualCoin CISSP, PMP, CCNP, MCSE, LPIC22019-10-08T13:55:30-03:00

Page load link

This website uses cookies and third party services.

Источник

Description

Zabbix Windows Eventlog monitoring at the Windows host

As example, the fact of Windows OS boot

Configuring

At the Windows host

Zabbix-agent

C:\ZA\conf\zabbix_agentd.conf

...
Server=192.168.166.149
...
ServerActive=192.168.166.149
...
Hostname=tmb_windows_17-77 # At the Zabbix-server there MUST be the same name of the Host in the Web-interface. HOSTNAME of this system can be different
...

Restart ZA service

At Zabbix-server

Create host «tmb_windows_17-77«

At the Windows host in ZA config there MUST be the same name (Hostname=…)

Create Item

For example, we need to get only logs with eventId 6005 (this is the fact of the Log Service running, and it means Windows OS boot)

Name: «Log of the system boot»

Type: Zabbix agent (active)

Key: eventlog[System,,,,6005,,] # eventlog[System,,,,,,] — all events will be logged

Type of information: Log

Update interval: 1m

Test

Reboot Windows host for 2 times, we will get in the Latest data of the tmb_windows_17-77 Host:

04/24/2022 04:07:20 PM    03/04/2022 11:56:43 AM    EventLog    Information    6005    Запущена служба журнала событий.
04/24/2022 04:06:02 PM    02/24/2022 01:50:07 PM    EventLog    Information    6005    Запущена служба журнала событий.

Источник

Мониторинг внешнего входа и выхода пользователей Windows

Данные будем брать из Журнал событий (англ. Event Log)
Панель управления\Все элементы панели управления\Администрирование\Просмотр событий
или (Win+R) команду eventvwr.msc
eventlog-Microsoft-Windows-TerminalServices-LocalSessionManager-Operational
LSM — Local Session Manager
RCM — Remote Connection Manager
Запрос для Ключа eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]

: eventlog-Microsoft-Windows-TerminalServices-LocalSessionManager-Operational

Пример Просмотр и анализ логов RDP подключений в Windows

Ключ в zabbix будет использоваться eventlog

eventlog[имя,<регулярное выражение>,<важность>,<источник>,<eventid>,<макс. кол-во строк>,<режим>]
eventlog[имя»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,<регулярное выражение>пропускаем пусто,<важность>пропускаем пусто,<источник>пропускаем пусто,<eventid>^(21|23|24|25)$,<макс. кол-во строк>пропускаем пусто,<режим>skip]
skip — пропустить обработку старых данных

eventlog[имя,<регулярное выражение>,<важность>,<источник>,<eventid>,<макс. кол-во строк>,<режим>]

Мониторинг журналов событий.
Журнал (лог)

имя — имя журнала событий
регулярное выражение — регулярное выражение описывающее требуемый шаблон содержимого
важность — регулярное выражение описывающее важность
Параметр может принимать следующие значения:
“Information”, “Warning”, “Error”, “Critical”, “Verbose” (начиная с Zabbix 2.2, работающих на Windows Vista или на более новых версиях)
источник — регулярное выражение, описывающее идентификатор источника (регулярное выражение поддерживается начиная с версии Zabbix 2.2.0)
eventid — регулярное выражение описывающее идентификатор(ы) событий
макс. кол-во строк — максимальное количество новых строк в секунду, которое агент будет отправлять Zabbix серверу или прокси. Этот параметр заменяет значение ‘MaxLinesPerSecond’ в zabbix_agentd.win.conf
режим — возможные значения:
all (по умолчанию), skip — пропустить обработку старых данных (влияет только на недавно созданные элементы данных).

Элемент данных должен быть настроен активной проверкой.

Примеры:
⇒ eventlog[Application]
⇒ eventlog[Security,,»Failure Audit»,,529|680]
⇒ eventlog[System,,»Warning|Error»]
⇒ eventlog[System,,,,^1$]
⇒ eventlog[System,,,,@TWOSHORT] — здесь используется ссылка на пользовательское регулярное выражение с именем TWOSHORT (заданное с типом Результат ИСТИНА, само выражение равно ^1$|^70$).

Обратите внимание, агент не может отправлять события из «Пересланные события» журнала.

Параметр режим поддерживается начиная с версии 2.0.0.
“Windows Eventing 6.0” поддерживается начиная с Zabbix 2.2.0.

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

Смотрите дополнительную информацию о мониторинге файлов журналов.

СПЕЦИФИЧНЫЕ КЛЮЧИ ЭЛЕМЕНТОВ ДАННЫХ

Триггер
logeventid
Проверка, совпадает ли ID события последней записи из журнала указанному регулярному выражению.
шаблон — регулярное выражение описывающее требуемый шаблон, в формате расширенных регулярных выражений POSIX.
Поддерживаемые типы значений: log
Возвращает:
0 — не совпадает
1 — совпадает

Изначально шаблон был взят с Windows Server Login monitor далее путь на гитхаб Server-Login-monitor-Zabbix

Для начала оригинальный шаблон автора который был скачен с гитхаба

# Server-Login-monitor-Zabbix
uses Microsoft-Windows-TerminalServices-LocalSessionManager windows log to find logins and logouts to server.
and fires alarm when a user logs in to a server
Simply import to zabbix and add the template to desired hosts.

#Сервер-Логин-монитор-Zabbix
использует журнал Windows Microsoft-Windows-TerminalServices-LocalSessionManager для поиска логинов и выходов на сервер.
и подает сигнал тревоги, когда пользователь входит на сервер
Просто импортируйте в zabbix и добавьте шаблон на желаемые хосты.

Имя шаблона Windows external login monitor
Группы Windows
Описание Monitor non administrator logins on server

Макросы
{$HIDELOGINS} => Administrator
(не проверять, не выводить триггер когда заходит пользователь Administrator)

: Windows external login monitor

Группы элементов данных
Log
RDP

Элементы данных
Имя Login to Remote desktop
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23)$,,skip]
Тип информации Журнал (Лог)
Интервал обновления 15s
Период хранения истории 90d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных
Log
RDP
Описание Monitor RDP login and logout
Активировано V

Предобработка
Шаги предобработки Имя Регулярное выражение Параметры User: (.*)\n Вывод \1
Для Русскоязычных систем Windows в Логе вместо User по Русскому пишется Пользователь получаем
Шаги предобработки Имя Регулярное выражение Параметры Пользователь: (.*)\n Вывод \1

: Элемент данных Windows external login monitor

Триггер
Имя {ITEM.LASTVALUE1} RDP login
Важность Высокая
Выражение проблемы
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23)$,,skip].logeventid(21)}=1
Генерация ОК событий Выражение восстановления
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23)$,,skip].logeventid(21)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание Fires alarm unless RDP login is administrator
Активировано V

: Триггер Windows external login monitor.jpg

Скачать шаблон

Далее первые изменения в шаблоне
Переведён полностью на Русский язык
Добавлены описания
Добавлен триггер на повторный вход 25

Имя шаблона Windows external login monitor
Видимое имя Монитор внешнего входа Windows
Описание Monitor non administrator logins on server
Мониторинг Логинов без прав администратора на сервере

Макросы
{$HIDELOGINS} => No я решил показывать все входы, не скрывая

: Windows external login monitor rus.jpg

Группы элементов данных
LOG-RDP&Local

Элементы данных
Имя Вход на удаленный рабочий стол
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]
Тип информации Журнал (Лог)
Интервал обновления 15s
Период хранения истории 90d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных
LOG-RDP&Local
Описание
Login to Remote desktop
Monitor RDP login and logout

Вход на удаленный рабочий стол
Монитор РДП вход и выход

Скрыть вход добавить макрос {$HIDELOGINS} Administrator

Активировано V

Предобработка
Для Русскоязычных систем Windows в Логе вместо User по Русскому пишется Пользователь получаем
Шаги предобработки Имя Регулярное выражение Параметры Пользователь: (.*)\n Вывод \1

: Элемент данных Windows external login monitor rus.jpg

Триггеры 2
Имя {ITEM.LASTVALUE1} RDP login
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(21)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(21)}=0

Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
21 — успешный Вход
Пожары сигнализации, если RDP логин администратора

Активировано V

: Триггер Windows external login monitor rus.jpg

Имя {ITEM.LASTVALUE1} RDP login povtor
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(25)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(25)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
25 — успешное переподключение
Пожары сигнализации, если RDP логин администратора
Активировано V

: Триггер 2 Windows external login monitor rus.jpg

Скачать Шаблон

Дальнейшие доработки
Мало инфы в триггере 1.Пользователь который подключился 2.IP-адресс откуда подключился 3.Код Сеанса 4.Имя ПК с которого выполнено подключение
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.

Сперва текущий актуальный шаблон на 12.01.2021, ниже как это делалось какие проблемы возникали и тд.

Скачать

19.08.2022
Для элемента данных «Получаем предыдущее значение для Windows LSM»
если Windows включен но никто не заходил данные пустые строки нет и элемент уходит в ошибку что тип не числовой, в предобработке при пустом значении делаем 0.

: Если пустое значение а тип числовой делаем 0

Имя шаблона Windows external login monitor
Видимое имя Монитор внешнего входа Windows
Группы Windows и Windows Server
Описание
Monitor non administrator logins on server
Мониторинг Логинов без прав администратора на сервере

Макрос
{$HIDELOGINS} => No

: Шаблон Монитор внешнего входа Windows.jpg

Группы элементов данных LOG-RDP&Local

Элементы данных 5

: Элементы данных Монитор внешнего входа Windows

Элемент данных
Имя Вход в Windows LSM
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
Login to Remote desktop
Monitor RDP login and logout

Вход на удаленный рабочий стол
Монитор РДП вход и выход

17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — получено уведомление о запуске оболочки
23 — выход из сеанса
24 — отключен
25 — успешное переподключение
39 — (Session <A> has been disconnected by session <B>) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента).
Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
40 — Здесь нужно смотреть на код причины отключения в событии. Например:
Описание: «Сеанс <X> был отключен, код причины <Z>»
Сенас * был отключен, код причины 0
reason code 0 (No additional information is available)– обычно говорит о том, что пользователь просто закрыл окно RDP клиента, обычно в паре с идентификатором события 24
reason code 1 Отключение было инициировано административным инструментом на сервере в другом сеансе.
reason code 2 Отключение произошло из-за принудительного выхода из системы, инициированного административным инструментом на сервере в другом сеансе.
reason code 3 Таймер ограничения сеанса простоя на сервере истек.
reason code 4 Таймер ограничения активных сеансов на сервере истек.
reason code 5 (The client’s connection was replaced by another connection) – пользователь переподключился к своей старой сессии.
Сенас * был отключен, код причины 5 — Другой пользователь подключился к серверу, принудительно отключив текущее соединение. «Соединение клиента было заменено другим соединением». (Происходит, когда пользователь повторно подключается к сеансу RDP, обычно в паре с идентификатором события 25)
reason code 6 На сервере закончились доступные ресурсы памяти.
reason code 7 Сервер отказал в соединении.
reason code 8 Сервер отказал в соединении из соображений безопасности.
reason code 9 Пользователь не может подключиться к серверу из-за недостаточных прав доступа.
reason code 10 Сервер не принимает сохраненные учетные данные пользователя и требует, чтобы пользователь вводил свои учетные данные для каждого подключения.
reason code 11 (User activity has initiated the disconnect) – пользователь сам нажал на кнопку Disconnect в меню (Пуск отключение).
Отключение было инициировано пользователем, отключившим свой сеанс на сервере, или инструментом администрирования на сервере.
reason code 12 Отключение было инициировано пользователем, завершившим сеанс на сервере.
Сенас * был отключен, код причины 12 — Отключение было инициировано пользователем, завершившим сеанс на сервере

Определяет Windows Vista — Server typedef enum _ExtendedDisconnectReasonCode exDiscReasonNoInfo exDiscReasonAPIInitiatedDisconnect exDiscReasonAPIInitiatedLogoff exDiscReasonServerIdleTimeout exDiscReasonServerLogonTimeout exDiscReasonReplacedByOtherConnection exDiscReasonOutOfMemory exDiscReasonServerDeniedConnection exDiscReasonServerDeniedConnectionFips exDiscReasonServerInsufficientPrivileges exDiscReasonServerFreshCredsRequired exDiscReasonRpcInitiatedDisconnectByUser exDiscReasonLogoffByUser exDiscReasonLicenseInternal exDiscReasonLicenseNoLicenseServer exDiscReasonLicenseNoLicense exDiscReasonLicenseErrClientMsg exDiscReasonLicenseHwidDoesntMatchLicense exDiscReasonLicenseErrClientLicense exDiscReasonLicenseCantFinishProtocol exDiscReasonLicenseClientEndedProtocol exDiscReasonLicenseErrClientEncryption exDiscReasonLicenseCantUpgradeLicense exDiscReasonLicenseNoRemoteConnections exDiscReasonLicenseCreatingLicStoreAccDenied exDiscReasonRdpEncInvalidCredentials exDiscReasonProtocolRangeStart exDiscReasonProtocolRangeEnd } ExtendedDisconnectReasonCode; 2008 билиотека MsTscAx.dll
{
= 0, Никакой дополнительной информации нет.
= 1, Приложение инициировало отключение.
= 2, Приложение вышло из системы клиента.
= 3, Сервер отключил клиента, потому что клиент бездействовал в течение периода времени, превышающего назначенный период ожидания.
= 4, Сервер отключил клиента, поскольку клиент превысил период, отведенный для подключения.
= 5, Подключение клиента было заменено другим подключением.
= 6, Нет свободной памяти.
= 7, Сервер отказал в соединении.
= 8, Сервер отказал в соединении из соображений безопасности.
= 9, Сервер отказал в соединении из соображений безопасности.
= 10, Требуются новые учетные данные.
= 11, Действия пользователя привели к отключению
= 2, Пользователь вышел из системы, отключив сеанс.
= 256, Ошибка внутреннего лицензирования.
= 257, Сервер лицензий недоступен.
= 258, Действующей лицензии на программное обеспечение не было.
= 259, Удаленный компьютер получил недействительное лицензионное сообщение.
= 260, Идентификатор оборудования не соответствует идентификатору, указанному в лицензии на программное обеспечение.
= 261, Ошибка клиентской лицензии.
= 262, Проблемы с сетью возникли во время протокола лицензирования.
= 263, Клиент преждевременно прервал лицензионный протокол.
= 264, Сообщение о лицензировании было зашифровано неправильно.
= 265, Не удалось обновить или продлить лицензию на клиентский доступ локального компьютера.
= 266, Удаленный компьютер не имеет лицензии на прием удаленных подключений.
= 267, При создании раздела реестра для хранилища лицензий была получена ошибка отказа в доступе.
= 768, Обнаружены неверные учетные данные.
= 4096, Начало диапазона внутренних ошибок протокола. Дополнительные сведения см. В журнале событий сервера.
= 32767 Конец диапазона внутренних ошибок протокола.
trong>

Скрыть вход добавить макрос {$HIDELOGINS} Administrator
(Win+R) команду eventvwr.msc

Элемент данных Вход в Windows LSM

Элемент данных
Имя Получаем предыдущее значение для Windows LSM
Тип Zabbix агент
Ключ system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»]
Тип информации Числовой (целое положительное)
Интервал обновления 1m
Пользовательские интервалы Переменный
Период хранения истории Storage period 31d
Период хранения динамики изменений Storage period 31d
Отображение значения Как есть
Группы элементов данных LOG-RDP&Local
Описание
Получаем значение, для закрытия триггера на пользователь отключен

Если RDP закрыт, а не завершен то в журнале
24 — отключен
после триггер действие завершение и
23 — выход из сеанса (закрывает триггер)

А если завершен, в логе
23-выход из сеанса
24 — отключен
И по этому триггер на отключение не закрывается

Поэтому смотрим предпоследнюю запись если она 23 триггер не срабатывает.

Активировано V

Предобработка
Шаги предобработки
1 Имя Обрезать Параметры [2] Event ID
2 Имя Обрезать Параметры :

Вход в Windows RCM

Элемент данных
Имя Вход в Windows Security
Тип Zabbix агент (активный)
Ключ eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
Тип входа» указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера: (Попытка входа)
(Имя целевого сервера: FS Имя учетной записи: User) Были использованы учетные данные следующей учетной записи:
Имя учетной записи:Admin
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен

(Win+R) команду eventvwr.msc

Активировано

Элемент данных Вход в Windows Security

Элемент данных
Имя Вход в Windows RCM
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational»,,,,^(1149|4624|4625)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя

(Win+R) команду eventvwr.msc

Активировано

Элемент данных Вход в Windows RCM

Элемент данных
Имя ClientName
Тип Zabbix агент (активный)
Ключ 1
Тип информации Текст
Интервал обновления 60s
Период хранения истории Storage period 90d
Группы элементов данных LOG-RDP&Local
Описание
через power shell запрашиваем Get-TSSession -State Active | Format-List ClientName

Активировано

Элемент данных ClientName

Проверка со стороны сервера
zabbix_get -s 192.168.ххх.ххх -k 1

На стороне заббикс агента в конфигурации прописываем следующее
Конфигурация агента ссылается на скрипт повершела
UserParameter=1, powershell C:\zabbix\Scripts\1.ps1

Содержание скрипта 1.ps1
Get-TSSession -ComputerName Program
или
Get-TSSession
или
Get-TSSession | Format-List ClientName
или
Get-TSSession -State Active | Format-List ClientName

Триггеры 4

Триггеры Монитор внешнего входа Windows

Триггер
Имя RDP auth {{ITEM.VALUE}.iregsub(«(Пользователь: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(источника: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(Код сеанса: .*)», «\1»)}
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(21)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(21)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
21 — успешный Вход
Пожары сигнализации, если RDP логин администратора
Активировано V

Теги
Trigger tags
Имя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «\1»)} Значение

Триггер Входа Аунтификации Монитор внешнего входа Windows

Триггер
Имя RDP auth povtor {{ITEM.VALUE}.iregsub(«(Пользователь: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(источника: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(Код сеанса: .*)», «\1»)}
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(25)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(25)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
25 — успешное переподключение
Пожары сигнализации, если RDP логин администратора
Активировано V

Теги
Trigger tags
Имя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «\1»)}

Триггер Повтора Входа Аунтификации Монитор внешнего входа Windows

Триггер
Имя RDP auth otkl {{ITEM.VALUE}.iregsub(«(Пользователь: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(источника: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(Код сеанса: .*)», «\1»)}
Важность Информация
Выражение проблемы
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(24)}=1 and
{Windows external login monitor:system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»].last()}<>23 and
{Windows external login monitor:system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»].diff(0)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(24)}=0 or
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(24)}=1 and
{Windows external login monitor:system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»].last()}=23
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
23 — выход из сеанса (закрывает триггер)
24 — отключен

Срабатывает если последняя запись 24 и предпоследняя не равна 23
не создавалось множество указано diff

Активировано V

Теги
Trigger tags
Имя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «\1»)} Значение

Триггер Отключен Входа Аунтификации Монитор внешнего входа Windows

Триггер
Имя RDP auth {{ITEM.VALUE}.iregsub(«(Тип входа: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(Имя рабочей станции: .*)», «\1»)}
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip].logeventid(4624)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip].logeventid(4624)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Вход с Имя компьютера подключенного по RDP Лог 4624
Активировано

Триггер Входа Имя ПК Аунтификации Монитор внешнего входа Windows

Про Инфу в триггер 1.Пользователь который подключился 2.Код Сеанса 3.IP-адресс откуда подключился или локальный вход 4.Имя ПК с которого выполнено подключение
На примере диспетчера задач вкладка пользователи
Windows 10

RDP-подключение.jpg

Windows 7

Имя клиента.jpg

Из журнала Microsoft-Windows-TerminalServices-LocalSessionManager/Operational можем получить
Пользователь: источника: Код сеанса:

Локально: 21
Службы удаленных рабочих столов: Успешный вход в систему:

/Пользователь: COMPTV\Медиа
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ

Посети: 21
Службы удаленных рабочих столов: Успешный вход в систему:

/Пользователь: COMPTV\Медиа
Код сеанса: 2
Адрес сети источника: 192.168.175.8

Посети: 25
Службы удаленных рабочих столов: Успешное переподключение сеанса:

Пользователь: COMPTV\Медиа
Код сеанса: 1
Адрес сети источника: 192.168.175.8

По сети: 24
Службы удаленных рабочих столов: Сеанс был отключен:

Пользователь: COMPTV\Медиа
Код сеанса: 1
Адрес сети источника: 192.168.175.8

Локально 23
Службы удаленных рабочих столов: Успешный выход из сеанса:

Пользователь: COMPTV\Медиа
Код сеанса: 1

Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)

Триггер RDP auth Пользователь: Домен\MamzikovAA источника: 192.168.175.8 Код сеанса: 4

21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: Домен\MamzikovAA
Код сеанса: 4
Адрес сети источника: 192.168.175.8

23
Службы удаленных рабочих столов: Успешный выход из сеанса:
Пользователь: Домен\MamzikovAA
Код сеанса: 4

24
Службы удаленных рабочих столов: Сеанс был отключен:
Пользователь: Домен\MamzikovAA
Код сеанса: 4
Адрес сети источника: 192.168.175.8

25
Службы удаленных рабочих столов: Успешное переподключение сеанса:
Пользователь: Домен\Администратор
Код сеанса: 1
Адрес сети источника: 192.168.175.10

Но Имя ПК с которого выполнено подключение в данном логе нет
оно есть в eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip]
Журналы Windows — Безопасность
Вход с Имя компьютера подключенного по RDP Лог 4624
Тип входа: Имя рабочей станции:
Описание Кодов:
1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера: (Попытка входа)
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен

(Win+R) команду eventvwr.msc

4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
Вход с учетной записью выполнен успешно.
Субъект:
ИД безопасности: S-1-5-18
Имя учетной записи: FSServer$
Домен учетной записи: WORKGROUP
Код входа: 0x3e7
Тип входа: 10 не совпадает с кодом сеанса
Новый вход:
ИД безопасности: S-1-5-21-52705171-3967056117-1643963046-500
Имя учетной записи: Администратор
Домен учетной записи: FSServer
Код входа: 0x163d7532
GUID входа: {00000000-0000-0000-0000-000000000000}
Сведения о процессе:
Идентификатор процесса: 0xdf0
Имя процесса: C:\Windows\System32\winlogon.exe
Сведения о сети:
Имя рабочей станции: FSServer
Сетевой адрес источника: 192.168.175.8
Порт источника: 41509
Сведения о проверке подлинности:
Процесс входа: User32
Пакет проверки подлинности: Negotiate
Промежуточные службы: —
Имя пакета (только NTLM): —
Длина ключа: 0
Данное событие возникает при создании сеанса входа. Оно создается в системе, вход в которую выполнен.
Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.
В поле «Тип входа» указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).
Поля «Новый вход» указывают на учетную запись, для которой создан новый сеанс входа, то есть на учетную запись, с которой выполнен вход.
В полях, которые относятся к сети, указан источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.
Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
— GUID входа — это уникальный идентификатор, который позволяет сопоставить данное событие с событием KDC.
— В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
— Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
— Поле «Длина ключа» содержит длину созданного ключа сеанса. Это поле может иметь значение «0», если ключ сеанса не запрашивался.

4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера:
Выполнена попытка входа в систему с явным указанием учетных данных.
Субъект:
ИД безопасности: Домен\Администратор
Имя учетной записи: Администратор
Домен учетной записи: Домен
Код входа: 0x27854ae
GUID входа: {a5064763-d331-b7a3-1f58-df1c9bbdb9e9}
Были использованы учетные данные следующей учетной записи:
Имя учетной записи: back
Домен учетной записи: Домен
GUID входа: {00000000-0000-0000-0000-000000000000}
Целевой сервер:
Имя целевого сервера: nas2
Дополнительные сведения: nas2
Сведения о процессе:
Идентификатор процесса: 0x4
Имя процесса:
Сведения о сети:
Сетевой адрес: —
Порт: —
Данное событие возникает, когда процесс пытается выполнить вход с учетной записью, явно указав ее учетные данные. Это обычно происходит при использовании конфигураций пакетного типа, например, назначенных задач, или выполнении команды RUNAS

4647 — выход
Выход, запрошенный пользователем:
Субъект:
ИД безопасности: S-1-5-21-59707171-3867655147-1643063056-500
Имя учетной записи: Администратор
Домен учетной записи: FSServer
Код входа: 0x163d7532
Данное событие возникает, когда выход начат. Дальнейшие действия, запрошенные пользователем, не выполняются. Данное событие можно рассматривать как событие выхода.

4634 — выход (23 в 2 журнале)
Выполнен выход учетной записи из системы.
Субъект:
ИД безопасности: Домен\MamzikovAA
Имя учетной записи: MamzikovAA
Домен учетной записи: Домен
Код входа: 0x28a9692
Тип входа: 3
Данное событие возникает при уничтожении сеанса входа. Его можно однозначно связать с событием входа с помощью значения «Код входа». Коды входа остаются уникальными после перезагрузки, но они уникальны только на одном компьютере.

Пример eventlog Security 4624.jpg

Сделать 2 элемента в 1 триггер {ITEM.VALUE} получаем только значение с одного элемента которое первее отработает, второй элемент уже не попадает вариант отпадает. Сделать 2 триггера для того чтобы видеть имя подключившегося ПК как то не целесообразно.
В общем Элемент Вход в Windows Security — Отключен и Триггер так же отключен RDP auth {{ITEM.VALUE}.iregsub(«(Тип входа: .*)», «\1»)} {{ITEM.VALUE}.iregsub(«(Имя рабочей станции: .*)», «\1»)}

Вход в Windows RCM-Remote Connection Manager

Windows RCM-Remote Connection Manager

1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя

(Win+R) команду eventvwr.msc

Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operationa

1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)

Службы удаленных рабочих столов: Успешная проверка подлинности пользователя:
Пользователь: Администратор
Домен: FSServer
Адрес источника сети: 192.168.175.8

Следующая проблемка
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.
Копятся не закрываются триггеры

Откл копятся.jpg

Разница Завершения Сеанса пользователя и отключения

Вход и Завершение сеанса RDP.jpg

Вход и Закрытие RDP на крестик.jpg

Так как

По завершению и закрытию сеанса RDP

Завершение сеанса
23 — выход из сеанса (закрываем триггер все хорошо или не даем триггеру открыться)
24 — отключен

При закрытии сессии RDP на крестик
24 — отключен сработал триггер (выполним действие на завершение пользователя) и дальше его ничто уже не закроет так как 23 уже было в логе
23 — выход из сеанса, сработало действие на завершение сеанса пользователя по триггеру отключен

Открытие Срабатывание триггера отключённых пользователей происходить по 24 значению лога
а закрытие триггера по 23 значению лога

23 — выход из сеанса (закрывает триггер)
24 — отключен
Срабатывает если последняя запись 24 и предпоследняя не равна 23
не создавалось множество указано diff

По этому пришлось сделать еще один элемент который берет предыдущее значение из лога , уже не раз 15 секунд, а раз в 1 минуту.
Хотелось бы получать все с одного элемента но что делать.
system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»]

По отключенным триггер срабатывает если 24 и предыдущая строка не 23

Триггер на отключение срабатывает
С журнала последний код 24 — отключен .logeventid(24)}=1
И
Предыдущее значение не равно 23 выход из сеанса .last()}<>23
И
не создавалось множество указано .diff(0)}=1
Закрытие триггера на отключение
С журнала последнее значение не 24 — отключен .logeventid(24)}=0
Или
С журнала последний код 24 — отключен .logeventid(24)}=1
И
Предпоследнее значение 23 — выход из сеанса .last()}=23

Так же была попытка сделать через теги , корреляцию.

Идея была в чем до функции diff создавалось множество триггеров на отключение с обычного элемента, их надо было закрывать старые или не открывать новые , чтоб они не дублировались. у нас есть значение тега код сеанса например 2 зная имя триггера и код сеанса даем параметр не открывать больше 1 если уже открыт, но тег 2 как только триггер сработал он у нас есть в значении переменной {EVENT.TAGS} но спустя 15 секунд повторного запроса элемента или раз в 1 минуту предыдущего значения элемента , переменная тега {EVENT.TAGS} обнуляется пустая и корреляция не работает, хотя тег сбоку триггера при открытии запоминается и держится пока триггер не закроется.

Теги и регулярное выражение {{ITEM.VALUE}.iregsub(«…….)», «\1»)}

Добрый день! Поясните правильно ли я понимаю работу тегов или нет.

Есть элемент данных для мониторинга пользователей windows на основе лога
eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]

Запрашиваю каждую 1 минуту

Описание
17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — получено уведомление о запуске оболочки
23 — выход из сеанса
24 — отключен
25 — успешное переподключение

Триггер на отключившихся пользователей которые просто закрыли на крестик сессию RDP , а не завершили сеанс.
Проблема
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(24)}=1
Восстановление
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(24)}=0

В имени тега есть регулярка которая показывает код сеанса данного пользователя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «\1»)}

Суть вопроса в чем
Кто то отключился Сработал триггер, регулярка отработала присвоила триггеру тег например 2

Дальше у меня действие спустя 5 минут завершить сессию данного пользователя (мало ли просто обрыв инет пропал даю 5 минут ожидания)
Элемент за это время у нас еще отпроситься 4 раза, естественно там регулярки не будет, так как изменений в логе нет по этой сессии

Сам же отвечу пустые Логи не приходят, только идут по штампу времени значит значение тега сохраняется, так же если будут изменения лога присвоится другой ID и триггер закроется или сработает другой или действия.

И когда срабатывает действие выполнить команду logoff «{EVENT.TAGS}» /server:{HOST.CONN}
то макрос {EVENT.TAGS} выходит пустой

Сам отвечу не будет пустым, выше ответ почему.

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

tags-vopros0

tags-vopros1

В некоторых попытках в триггер можно получить предыдущее значение журнала (лога) но уже нельзя сравнить id

Открываем Журнал событий Run (Win+R) команду eventvwr.msc

Откуда можем взять данные:
1. Журналы Windows — Безопасность eventlog[«Security»,,,,^(1100|1102|4624|4648|4634|4647)$,,skip]

1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи:
Целевой сервер: — Имя целевого сервера:
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен

2. Microsoft-Windows-TerminalServices-LocalSessionManager/Operational eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]

17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — полученно уведомление о запуске оболочки
23 — выход из сеанса (закрывает триггер) (4634 в 1 журнале)
24 — отключен
25 — успешное переподключение
39 — (Session <A> has been disconnected by session <B>) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента).
Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
40 — Здесь нужно смотреть на код причины отключения в событии. Например:
reason code 0 (No additional information is available)– обычно говорит о том, что пользователь просто закрыл окно RDP клиента.
reason code 5 (The client’s connection was replaced by another connection) – пользователь переподключился к своей старой сессии.
reason code 11 (User activity has initiated the disconnect) – пользователь сам нажал на кнопку Disconnect в меню.

3. Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operationa eventlog[«Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational»,,,,^(1149|4624|4625)$,,skip]

1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя

Об значениях в триггерах как формируются
Регулярное выражение Совпадение значения с регулярным выражением <шаблона> и замена значения в соответствии с <выводом>.
Регулярное выражение поддерживает извлечение до 10 захваченных групп в \N последовательности.
Элемент данных станет неподдерживаемым в случае ошибки при поиске соответствия во входящем значении.
Параметры:
шаблон — регулярное выражение
вывод — шаблон форматирования вывода. \N (где N=1..9) — управляющая последовательность заменяется N-нной совпадающей группой.
Управляющая последовательность \0 заменяется совпадающим текстом
Поддерживается начиная с 3.4.0.
Пожалуйста, обратитесь в разделу регулярных выражений для ознакомления с некоторыми существующими примерами.

{ITEM.LASTVALUE<1-9>}
Последнее значение элемента данных N-го элемента данных в выражении триггера вызвавшего это оповещение.
Поддерживается начиная с 1.4.3. Это алиас для {{HOSTNAME}:{TRIGGER.KEY}.last(0)}
> Оповещения, основанные на триггерах
> Имена триггеров и описания Последнее значение N-го элемента данных из выражения триггера, который вызвал оповещение.
В веб-интерфейсе раскрывается в *НЕИЗВЕСТНО*, если последнее значение истории собрано более чем ZBX_HISTORY_PERIOD секунд назад (задается в defines.inc.php).
Поддерживается начиная с 1.4.3. Является алиасом к {{HOST.HOST}:{ITEM.KEY}.last()}

{ITEM.VALUE<1-9>}
Последнее значение N-го элемента данных в выражении триггера, если используется для отображения триггеров.
Историческое значение (точно когда произошло событие) N-го элемента данных из выражения триггера, если используется для отображения событий и оповещений.
Поддерживается начиная с Zabbix 1.4.3.

{HOSTNAME<1-9>}
Имя узла сети N-го элемента данных из триггера вызвавшего это оповещение.
Поддерживается в оповещениях авторегистрации начиная с версии 1.8.4.

{$MACRO}
Пользовательские макросы. Поддерживается в именах триггеров и в описаниях элементов данных начиная с версии 1.8.4.

Имя клиента из реестра
Есть query session, query user, quser /server 192.168.128.50, query user /server 192.168.128.50, query session /server 192.168.128.50,
query session /server 192.168.128.50 /counter, Qwinsta, tasklist , но они показывают только имя пользователя.
переменная %CLIENTNAME%
echo %CLIENTNAME%
echo %SESSIONNAME%

HKCU\Environment\Clientname
HKEY_CURRENT_USER\Volatile Environment\1 — CLIENTNAME (SESSIONNAME)
HKEY_USERS\S-1-5-21-3002483080-1650114603-3144430796-1000\Volatile Environment\1 — CLIENTNAME
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer, параметр «LOGON USER NAME»

Поставьте, PSTerminalServices (http://psterminalservices.codeplex.com/ … view/65937) и с помощью
Имена пользователей я вырезал. Модуль можно ставить на любой машине с powershell
PS C:\Windows\system32> Get-TSSession -ComputerName TSFarm501

WshShell = Новый COMОбъект(«WScript.Shell»);
WshSysEnv = WshShell.Environment(«Process»);
Сообщить(«Имя компьютера «+WshSysEnv.Item(«CLIENTNAME»));
Работает только в терминальной сессии

%USERPROFILE%\AppData\Local\Temp
%USERPROFILE%\AppData\Local\Temp

для команды для текущего пользователя
reg query «HKCU\Volatile Environment»
Для конкретного пользователя
HKEY_USERS\S-1-5-21-3002483080-1650114603-3144430796-1000\Volatile Environment

реестр всех пользователей
C:\mkdir c:\Temp
Regedit.exe /e c:\temp\yourname.reg

Вычисляемый элемент
last(«eventlog[\»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational\»,,,,^(21|23|24|25|39|40)$,,skip]») не катит поле не числовое
logeventid(«eventlog[\»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational\»,,,,^(21|23|24|25|39|40)$,,skip]»,23) получаем 0 или 1

date
Текущая дата в формате ГГГГММДД. Поддерживаемые типы значений: любые Пример результата: 20150731

time
Текущее время в формате ЧЧММСС. Поддерживаемые типы значений: любые Пример возвращаемого значения: 123055

fuzzytime (сек)
Проверка, на сколько отличается значение элемента данных (как штамп времени) от времени Zabbix сервера. сек — секунды Поддерживаемые типы значений: float, int
Возвращает:
1 — если разница между штампом времени значения элемента данных и штампом времени Zabbix сервера меньше или равна сек секунд
0 — в противном случае.
Обычно используется с system.localtime для проверки, что локальное время синхронизировано с локальным временем Zabbix сервера. Обратите внимание, что элемент данных ‘system.localtime’ должен быть настроен пассивной проверкой.
Также можно использовать с ключом vfs.file.time[/путь/к/файлу,modify] для проверки, что файл не обновлялся длительное время.
Пример: fuzzytime(60)=0 > обнаружение проблемы, если разница во времени больше 60 секунд

Имя Time diff
Тип Вычисляемое
Ключ system.localtime.fuzzytime
Формула fuzzytime(system.localtime,60)
Тип инфы Числовой (целое положительное)
Интервал 1m

Если 3 последних 0 т.е. 0+0+0 = 0 значит триггер срабатывает у нас есть расхождение более чем на 1 минуту
Триггер
system.localtime.fuzzytime.sum(#3)}=0

system.localtime -формат ДД.ММ.ГГГГ ЧЧ:ММ:СС

wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /f:text|FIND /I «Event ID» — от самых старых к новым 2строки
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID» — от новых к старым строкам пример 2строки
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»

/c:<Count> Задает максимальное число событий для чтения.
/rd:<Direction> Указывает направление чтения событий. <Direction>может иметь значение true или false. Если значение равно true, то первыми возвращаются самые последние события.
/f:<Format> Указывает, что выходные данные должны быть в формате XML или текстовый формат. Если <Format> параметр имеет значение XML, выходные данные отображаются в формате XML. Если <Format> является текстом, выходные данные отображаются без XML-тегов. Значение по умолчанию — Text.

FIND /I — Поиск без учета регистра символов «строка» — Искомая строка
FIND /N — Вывод номеров отображаемых строк.
FIND /V — Вывод всех строк, НЕ содержащих заданную строку.

Проверка через заббикс
zabbix_get -s 192.168.ХХХ.ХХХ -p 10050 -k system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»]

Кото для теста хочет подключатся к учетной записи по RDP без пароля не обходимо выполнить следующее

При попытке подключиться к компьютеру под управлением Windows с помощью средства дистанционного управления рабочим столом появляется следующее сообщение об ошибке: Вход в систему невозможен из-за ограничений для учетной записи.
Подобное поведение наблюдается, если используемая для подключения учетная запись имеет пустой пароль. Невозможно установить подключение к удаленному рабочему столу, используя учетную запись с пустым паролем.
Чтобы устранить эту проблему и подключиться к удаленному рабочему столу, войдите в систему с консоли компьютера и установите пароль для используемой учетной записи.
Такое поведение является особенностью данного продукта
Ограничения, накладываемые пустым паролем, можно отключить, используя политику. Найдите и измените соответствующую политику, выполнив следующие действия:
Нажмите кнопку Пуск, выберите пункт Выполнить (win + R), введите команду gpedit.msc и нажмите кнопку OK, чтобы запустить редактор объектов групповой политики.
Откройте раздел Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности\Учетные записи: Limit local account use of blank passwords to console logon only.
Дважды щелкните элемент Limit local account use of blank passwords to consol logon only.(:ограничить использования пустых паролей только для консолей входа)
Выберите отключен и нажмите кнопку OK.
Закройте редактор групповой политики.
Примечание. По умолчанию данная политика включена.

Источник

Подготовка

Мониторинг событий безопасности MS Windows Server

События ИБ MS Windows Server Security Log

Способы мониторинга событий ИБ MS Windows Server

P.S.

Мониторинг событий безопасности Unix систем

События ИБ в Unix системах, подходящие для всех

Некоторые критически важные события в Unix системах

Способы мониторинга ИБ в Unix системах

Мониторинг событий ИБ на сетевых устройствах

Способы мониторинга

Juniper и Syslog

P.S.

Заключение

Zabbix – Monitor Event Log on Windows

Zabbix – Monitor Event Log on Windows

Hardware List:

Zabbix Playlist:

Zabbix Related Tutorial:

Zabbix Agent Configuration Required

Tutorial – Zabbix Monitor Windows Log File

Related Posts

Description

Configuring

At the Windows host

At Zabbix-server

Test