мониторинг windows серверов zabbix

Мониторинг Microsoft Windows на базе Zabbix

03.09.2019 Update

Кстати новые шаблоны уже доступны

Сегодня мы расскажем о том, как мы ведем мониторинг Windows систем (в скором времени планируем такой же обзор про Linux и как обычно с доступным шаблоном).

Наш путь начался, как часто бывает, со штатного шаблона Zabbix «Template OS Windows Active» для мониторинга Windows-клиентов (рабочие станции и сервера), но ровно через неделю активного использования поняли, в нем много чего не хватает.

Так мы и начали его кардинальную переделку, часть оставили и добавили много чего нового.

Общая концепция

1. Отдельные настройки шаблона в файле os_windows_active.conf

2. Отдельный скрипт PowerShell — os_windows_active.ps1 для работы шаблона, при этом скрипт должен быть универсальным и работать на большинстве операционных систем с минимумом внешних зависимостей.

3. Шаблон должен быть не зависимым от языка операционной системы, поэтому лучше всего снимать данные со счётчиков используя либо WMI, либо скрипт + zabbix trapper.

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

Основные возможности

Triggers

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

Physical Memory

Physical disk

Logical disk

Network

Operation system

Инвентаризация

Так как клиенты имеют разные компьютеры, нам требуется получать краткую инвентаризацию по ним, поэтому мы добавили в шаблон сбор данных о компьютере, и этими данными заполняем стандартные поля Zabbix Inventory:

Графики

Мы сделали несколько полезных общих графиков, чтобы наглядно видеть общее состояние клиента и отдельных его подсистем.

OS overview performance

OS detail performance

Где скачать

Данный шаблон и скрипт вы можете бесплатно скачать с GitHub, а также в Zabbix Share.

Наши шаблоны мы продолжим выкладываем в открытый доступ в наш репозитарий Zabbix.

Системное администрирование серверов и DevOps

Источник

ZABBIX: мониторинг кластера Windows Server

Как известно Zabbix является достаточно мощной системой мониторинга, про нее уже достаточно много написано. Однако недавно у меня встала задача организовать мониторинг кластера Windows Server 2003 силами Zabbix. Поиск в гугле не дал сразу ответа на то как это сделать, и потому пришлось немного подумать…
О том? что из этого получилось под катом…

Исходные данные:
Имя кластера: MS-CLUSTER.DOMAIN.COM
Состоят из 2 узлов.
Узел1: MS-NODE1.DOMAIN.COM
Узел2: MS-NODE2.DOMAIN.COM
IP-адрес узла1: 192.168.0.1
IP-адрес узла2: 192.168.0.2
IP-адрес самого кластера: 192.168.0.3

Задача:
Организовать мониторинг самого кластера и его узлов.

Решение:
На самом деле все очень легко. Но думаю есть люди не знают как это сделать и им очень надо, вот для них эта статья.
Для начала нам понадобится zabbix agent под платформу Windows (можно найти на официальном сайте).
Точнее даже два файла: zabbix_agentd.exe (сам агент) и zabbix_agentd.conf (его конфиг).
Прежде чем ставить давайте поправим конфиг:

# Задаем уровень дебагинга
DebugLevel=3

#Задаем где будет лежать log-файл
LogFile=C:\Zabbix_agent\Zabbix_agentd.log

#Разрешаем выполнение удаленных команд агенту (может пригодиться)
EnableRemoteCommands=1

#Указываем DNS-имя zabbix-сервера
Server=zabbix.domain.com

# Порт, который будет слушать агент
ListenPort=10050

# Порт, который слушает наш сервер (значение по умолчанию)
ServerPort=10051

Это минимум. Его, как вы сами понимаете не достаточно, но это то что должно быть в конфиге обязательно на всех серверах.
Вот теперь начинаем вносить отличия. Сложность в том, что агент, слушая TCP порт не отличает еще и запросы на разные IP адреса (192.168.0.1 и 192.168.0.3 к примеру, когда активным будет первый узел). Дальше я расскажу как это сделать.
На сервере MS-NODE1.DOMAIN.COM создаем папку C:\Zabbix_agent\. Копируем туда два файла (конфиг и сам exe-шник). Переименовываем конфиг в zabbix_agentd_NODE1.conf Добавляем в конфиг следующие строчки.
# Указываем IP-адрес узла1, именно его агент и будет слушать.
ListenIP=192.168.0.1

Теперь у нас есть запущенный zabbix agent, который мониторит Узел1. Чтобы сделать поддержку самого кластера нужно следующее: копируем конфиг в файл zabbix_agentd_CLUSTER.conf
Изменяем там строчку:

Повторяем все вышеописанные действия на машине MS-NODE2.DOMAIN.COM.

Теперь нам необходимо сделать эту службу кластерной. Запускаем оснастку Cluster Administrator нажимаем File->New->Resource. Указываем данные:

Name: Zabbix Agent
Description: Server for monitoring
Resource type: Generic Service

Источник

Zabbix настройка мониторинга температуры

Появилась у меня потребность мониторить температуру windows серверов в Zabbix. Из систем мониторинга он мне больше всего нравится, поэтому смотрел в его сторону. Решение задачи оказалось неожиданно простым, о чем я и хочу вам рассказать.

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

То же самое на Debian 10, если предпочитаете его:

Текущая статья писалась для версии 2.4, все скриншоты приведены из нее. В настоящее время уже вышли более новые версии, но вся нижеизложенная инструкция не потеряла актуальности. Все будет работать и в новой версии.

Подготовка к мониторингу в Zabbix

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

Существует бесплатная утилита Open Hardware Monitor, которая может показывать температуру некоторых датчиков сервера. Вообще говоря, она много чего может показывать (напряжение, скорость вентиляторов, загрузку процессора), но в данном случае нас интересует только температура. У этой утилиты есть версия, работающая в командной строке. Из командной строки показания датчиков можно записывать в файл. Этот файл можно анализировать и забирать из него необходимую для мониторинга информацию. Дальше эта информация передается в сервер Zabbix с помощью опции UserParameter. Все достаточно просто и в то же время эффективно.

Приступим к реализации. Скачиваем GUI версию утилиты по ссылке, приведенной ранее и консольную версию OpenHardwareMonitorReport. Запускаем GUI на сервере и смотрим, какие датчики нам доступны для мониторинга.

Программа увидела несколько датчиков. С процессором все понятно, а вот три других датчика не ясно, чью температуру показывают. Я хотел мониторить температуру процессора и материнской платы. Узнать, какая температура относится к материнской плате можно несколькими способами. Конкретно в данной ситуации я просто запустил портированную версию AIDA64 и посмотрел, какие показания у датчика материнской платы:

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

Открываем файл 1.txt. Ищем там строки

Нас интересует выделенный текст. По нему мы будем вычленять температуру для мониторинга и передавать ее на Zabbix сервер. Создаем в этой же папке 2 bat файла следующего содержания:

CPUTemperature.bat

MotherTemperature.bat

Запускаем эти батники в командной строке и проверяем вывод. Там должны быть только цифры температуры:

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

Настройка Zabbix agent в Windows

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

Перезапускаем службу агента Zabbix, чтобы изменения вступили в силу.

Настройка мониторинга на Zabbix сервере

Теперь идем на сервер. У меня Zabbix установлен на сервере CentOS, хотя это не принципиально. Добавляем новый Item. Пойти можно двумя путями:

Параметр Temperature.CPU тот же самый, что и в файле конфигурации агента.

По аналогии создаем итем Mother Temperatue:

Нажимаем graph и смотрим график:

Запускаем GUI интерфейс и смотрим, какие датчики мы сможем мониторить:

Нас будет интересовать температура обоих ядер процессора. Теперь запускаем OpenHardwareMonitorReport.exe с выводом информации в текстовый файл. Смотрим, как выглядят строки с интересующей нас информацией:

Создаем два bat файла следующего содержания:

CPU1Temperature.bat

CPU2Temperature.bat

Редактируем конфигурационный файл zabbix_agentd.win.conf агента Zabbix на клиенте. Добавляем в конец две строки:

Перезапускаем службу агента, чтобы изменения вступили в силу.

Дальше идем на сервер Zabbix и по аналогии с предыдущим сервером создаем там Итемы мониторинга. Причем итемы создаем не в шаблоне, а в конкретном сервере, который будем мониторить. Параметр key в этих итемах будет соответственно Temperature.CPU1 и Temperature.CPU2 Ждем некоторое время и проверяем результат.

item became not supported

Во время отладки работ я столкнулся с проблемами. Периодически Item отваливались и получали статус: Not Supported. При этом в логах сервера были следующие записи:

То есть данные то собирались, то переставали собираться. Иногда, чтобы данные снова пошли, приходилось удалять итем и создавать его заново. Некоторое время я повозился, пока не понял, в чем дело.

Я обратил внимание, что при запуске батника из командной строки, вывод данных происходит с приличной задержкой в 3-5 секунд. В Zabbix по-умолчанию стоит параметр, по которому агент ожидает ответа от скрипта 3 секунды и на сервере есть подобный параметр, по которому сервер ждет ответа от агента 3 секунды. Если за это время данные не поступают, то итем переходит в статус Not Supported и данные с него не собираются.

Чтобы избавиться от этой ошибки, необходимо увеличить таймаут до 15-ти секунд. Меняем параметр в конфиге на клиентах и на сервере. Он и там и там один и тот же:

Потом перезапускаем сервер и агентов и ждем результатов. Больше ошибок быть не должно.

На этом, собственно настройка мониторинга температуры окончена. Можно дальше все оформить как полагается: настроить тригеры, оповещения, графики красивые нарисовать. Кому что нужно. Я себе вывел вот такую картинку для наглядности:

Источник

Zabbix: установка и базовая настройка системы мониторинга

Zabbix это open-source система мониторинга корпоративного уровня. На текущий момент Zabbix одна из самых популярных и функциональных бесплатных систем мониторинга. Благодаря простой установке и настройке Zabbix можно использовать для мониторинга крупных инфраструктур с сотнями серверов, так и для мелких конфигураций. В этой статье мы рассмотрим, как выполнить установку и базовую настройку сервера Zabbix 4.4 с веб-интерфейсом на базе Linux Ubuntu и CentOS, установить агенты Zabbix на сервере Windows и Linux, и добавить новые хосты в систему мониторинга.

Общий интерфейс Zabbix сервера представлен на скриншоте ниже.

Из чего состоит Zabbix и что он может?

Zabbix простой установке и настройке, написан на C (сервер, прокси и агент) и PHP (фронтенд). Zabbix Server и Zabbix Proxy может работать только на Linux системах. Агент можно установить на большом количестве поддерживаемых ОС и платформах.

Инсталляция Zabbix сервера состоит из:

Обычно схема работы выглядит так:

Zabbix может работать со всеми известными протоколами, а благодаря системе внешних скриптов, Zabbix может выполнять и получать данные из любых исполняемых скриптов/бинарников.

Установка Zabbix Server в Linux (Ubuntu, CentOS)

В этой статье мы рассмотрим пример установки Zabbix Server 4.4 на Linux (на примере Ubuntu Server 18.4 и CentOS) через пакетный менеджер.

Перейдите на страницу загрузки https://www.zabbix.com/download и выберите репозиторий, соответствующий вашему дистрибутиву Linux. Готовые пакеты есть для всех популярных дистрибутивов.

Например, для установки Zabbix на Ubuntu 18.04 нужно последовательно выбрать :

Скачем и добавим репозиторий:

Теперь можно установить необходимые пакеты:

# apt install zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf zabbix-agent

Предполагаем, что на сервере уже установлены: nginx, MySQL/MariaDB, php и php-fpm. Теперь через пакетный менеджер установим сам сервер Zabbix и агент:

# dnf install zabbix-server-mysql zabbix-web-mysql zabbix-agent

Осталось создать базу данных для Zabbix в MySQL (вместо MySQL можно использовать PostgreSQL, просто замените в командах ‘mysql’ на ‘pgsql’).

Создайте базу данных и дайте права пользователю, из-под которого Zabbix будет обращаться к базе данных:

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

Измените конфигурационный файл /etc/zabbix/zabbix_server.conf, укажите пароль от вновь созданного пользователя.

Так как в моем случае веб сервером служит nginx, нужно изменить nginx.conf, раскомментировав следующие строчки

Выставим временную зону в PHP. В файле /etc/zabbix/php-fpm.conf раскомментируем строчку

Дополнительно можно выставить следующие параметры PHP в /etc/php.ini :

Добавьте службу zabbix-server в автозапуск и запустите ее:

# systemctl enable zabbix-server zabbix-agent nginx php7.2-fpm
# systemctl restart zabbix-server zabbix-agent nginx php7.2-fpm

Настройка веб-интерфейса Zabbix

Теперь нужно настроить frontend (веб-интерфейс) Zabbix. В браузере откройте указанный ранее URL адрес zabbix сервера. В моем случае это test.zabbix.local (или на домен, который вы указывали. Не забудьте прописать его у себя в hosts файле или на DNS сервере).

Убедитесь, что во всех требования инсталлятора указано ОК.

Укажите данные для подключения к БД. Используйте пользователя и пароль, который создали ранее.

Укажите название Zabbix сервера. Порт рекомендую оставлять стандартный – TCP 10051.

Не забудьте открыть данные порты. Например, на Zabbix сервере на базе CentOS можно открыть порты в firewalld с помощью firewall-cmd:

А на агенте достаточно открыть 10050:

Не забудьте перезагрузить firewalld:

На этом установка сервера Zabbix Server завершена.

На странице https://www.zabbix.com/download есть пошаговые инструкции для установки Zabbix Server на другие операционные системы, а так же инструкции как собрать zabbix-server из исходного кода или запустить его в docker контейнерах.

Установка Zabbix Agent в Windows

Попробуем установить Zabbix агент на сервер Windows и добавим его на наш сервер мониторинга Zabbix. Скачать версию Zabbix агент для Windows можно здесь: https://www.zabbix.com/download_agents.

Выберите нужную версию агента под Windows. Я выберу формат msi (amd64) (без OpenSSL). Если вы планируете устанавливать zabbix agent на сервера/компьютеры домена через групповые политики или SCCM, то можете скачать zip архив с бинарными файлами и конфигурационными файлами.

Запустите инсталлятор, примите лицензионное соглашение, укажите запрошенные данные. Обратите внимание, что в поле “Server or Proxy for active checks” я указал IP адрес в формате IP:PORT. Поскольку порт я оставлял стандартный, я пишу IP:10051.

Далее еще пару раз нажмем Next и Install.

После этого убедимся, что наш агент установлен. В списке служб должен появиться сервис Zabbix Agent.

На клиенте Windows нужно разрещить входящие подключения с IP адреса сервера Zabbix в Брандмауэре Windows:

Добавление устройства на Zabbix-сервере

Чтобы убедиться в работоспособности агента, нужно добавить хост testnode2 на Zabbix сервер и назначить ему проверки (checks).

При установке агента мы указывали сервер в формате IP:PORT как раз для активных проверок.

Нажмите Create host и заполните данные. Обратите внимание, что Host name хоста должен полностью совпадать с hostname машины или значением параметра Hostname в конфиге агента.

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

Эти интегрированные шаблоны имеют постфикс “active”, значит, будут использоваться активные проверки.

Нажмите Add. Чтобы не ждать пока сервер и агент увидят друг друга (обычно занимает пару минут), перезагрузите службу Zabbix Agent на testnode2 и проверьте лог агента (C:\Program Files\Zabbix Agent\zabbix_agentd.txt).

В этом разделе отображаются последние данные, которые пришли на сервер по выбранным хостам или группам хостов.

Обратите внимание на то, что в дашборде Zabbix висит уведомление о том, что служба BITS не запущена. Это уведомление появилось потому что мы назначили стандартные шаблоны нашему хосту. В одном из шаблонов был мониторинг сервиса BITS и соответствующий триггер, который срабатывает если служба BITS находится не в статусе Running.

На этом настройка Windows Agentа завершена.

Установка Zabbix Agent в Linux

Перед тем как мы запустим zabbix агент, нужно отредактировать конфигурационный файл /etc/zabbix/zabbix_agentd.conf. В нем нужно указать IP адрес сервера Zabbix для активных проверок.

После этого запустите сервис агента:

# service zabbix-agent start

Убедитесь, что агент успешно запустился.

Строка cannot parse list of active checks говорит о том, что на сервере нет активных проверок для этого хоста.

Перезагрузите Zabbix агент и проверьте лог.

Проверьте, что данные от агента появились на сервере Zabbix.

На этом настройка Zabbix-агента на Linux системе завершена. В следующей статье мы рассмотрим безагентный мониторинг доступности узлов в Zabbix через ICMP Ping.

Источник

Мониторинг событий информационной безопасности с помощью ZABBIX

Подготовка

Итак, для начала я установил сервер мониторинга 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

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

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

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

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

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

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

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

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

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

Таким образом тонны сообщений, генерируемых системами 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:
Меняем права на файл:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Juniper и Syslog

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

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

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

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

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

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

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

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

Источник