Мониторинг безопасности с помощью Zabbix

Споры об использовании открытого ПО (OpenSource) в задачах обеспечения безопасности идут очень давно. Как и у сторонников так и у противников этой идеи накопится неопровержимый запас аргументов в свою защиту. Однако, не смотря на это существуют зарекомендовавшие себя инструменты, которые хорошо подходят для целей ИБ. Таким примером может послужить использование системы мониторинга 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

Описание EventID	2008 Server	2003 Server
Очистка журнала аудита	1102	517
Вход с учётной записью выполнен успешно	4624	528, 540
Учётной записи не удалось выполнить вход в систему	4625	529-535, 539
Создана учётная запись пользователя	4720	624
Попытка сбросить пароль учётной записи	4724	628
Отключена учётная запись пользователя	4725	629
Удалена учётная запись пользователя	4726	630
Создана защищённая локальная группа безопасности	4731	635
Добавлен участник в защищённую локальную группу	4732	636
Удален участник из защищённой локальной группы	4733	637
Удалена защищённая локальная группа безопасности	4734	638
Изменена защищённая локальная группа безопасности	4735	639
Изменена учётная запись пользователя	4738	642
Заблокирована учётная запись пользователя	4740	644
Имя учётной записи было изменено	4781	685

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

Способы мониторинга событий ИБ 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.

Спасибо за внимание. :)

По материалам @VladimirShpakovskiy на Хабре