graylog - auditbeat

Сбор и анализ событий безопасности в graylog

Сегодня мы рассмотрим очередной ключевой компонент graylog - sidecar, затем посмотрим как использовать data shipper (поставщик данных) auditbeat и увидим к чему всё это в итоге может привести.

Спойлер: к интересным дашбордам.

Что же за сайдкары?

Начнем с далека, с того что в составе graylog есть собственная система управления конфигурациями. Как бы это неожиданно не казалось, но это факт. И управляет эта система конфигурациями сборщиков логов, или коллекторами. В качестве таких коллекторов поддерживаются всевозможные beats (filebeat, winlogbeat и все остальные). Система очень удобная, особенно в тех случаях если у вас множество однотипных серверов (с одинаковыми или похожими ролями).

Схема работы sidecar изображена разработчиками graylog ниже.

Для того, чтобы воспользоваться этим замечательным функционалом, нужно установить на серверы собственно сервис sidecar.

$ sudo rpm -i graylog-sidecar-1.0.0-1.x86_64.rpm

Сами бинарники есть под все основные платформы (в том числе и под windows), взять их можно с гитхаба (https://github.com/Graylog2/collector-sidecar/releases).
Единственное, что нужно прописать в конфиге sidecar.yml после установки - это адрес graylog сервера (server_url) и токен для доступа к API (server_api_token). Мы не будем подробно на этом останавливаться, создается токен в разделе System / Authentication, а все подробности есть в официальных доках.
Сразу после успешного запуска sidecar появится в меню System / Sidecars.

К слову, каждый sidecar мониторит утилизацию CPU, что превращает их в лайтовые агенты наподобие того же zabbix.

Кратко про auditd

Ненадолго отскочим в сторону и поговорим про аудит событий в Linux. И как раз auditd - это ключевой юзерспейс компонент для подобного аудита.
В целом, аудит не обеспечивает дополнительную безопасность системы, скорее, он может быть использован для обнаружения нарушений уже используемых политик безопасности. Примеры работы аудита - это наблюдение за доступом к файлам, мониторинг системных вызовов, появление новых пользователей и многое другое. Подробно изучить использование auditd можно например здесь.
Свою информацию auditd пишет в отдельный лог файл (/var/log/audit/audit.log), но передавать эти логи например в graylog не слишком полезное дело. Ситуация в том, что часть информации в логах кодируется, для того чтобы пользователи не смогли подделать или изменить записи.
Но к счастью есть решение проблемы - и это auditbeat.

Знакомимся с шипперами

Не все знают, что elastic предоставляет множество поставщиков данных, и все они сгруппированы под термином beats. И auditbeat - это один из них. Ключевая его фича - эта модули, которых всего три, но покрывают при этом все необходимые задачи по аудиту событий безопасности.
Первый модуль так и называется - "auditd", этот модуль подключается напрямую к ядру и получает оттуда все необходимые события. Очень важно, что чтение лог файлов при этом вообще не происходит.
Второй модуль, "file integrity" занимается проверкой и отслеживанием изменений файлов. При старте он сканирует указанные директории и составляет хеши, с которыми периодически сверяется. И последний модуль под названием "system" находится пока в стадии экспериментального, он умеет собирать информацию о процессах, пользователях, сокетах и устанавливаемых пакетах.

Берем управление в свои руки

Итак, на текущий момент считаем, что у нас есть ферма серверов с установленными на них и graylog-sidecar и auditbeat.
Картина, будет выглядеть как на скриншоте ниже.

Казалось бы создавай шаблон конфигурации и распространяй ее на всю группу, но есть нюанс. Из коробки graylog умеет работать только с filebeat и winlogbeat, а остальных поставщиков придется добавлять руками.
К счастью это несложно, поэтому сразу этим и займемся.
Переходим в System / Sidecars, и затем в Configuration. В верхней части страницы идут конфиги, которые будут использоваться коллекторами (к ним мы еще доберемся), а вот в низу идут сами коллекторы.

Видим, что auditbeat'a среди них нету, поэтому нажимаем "Create Log Collector".

По большому счету отличий между filebeat и auditbeat в данном случае не очень много и в результате, выглядеть всё может как на скриншоте:

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

Теперь, когда сам коллектор создан, нужно создать подходящую конфигурацию, кнопка "Create Configuration". Сразу из выпадающего списка нужно не забыть выбрать свежесозданный auditbeat, так же можно назначить какой-нибудь цвет, пригодится в дальнейшем.
Саму конфигурацию можно немного расширить и добавить туда все три модуля auditbeat, например:

auditbeat.modules:

- module: auditd
  audit_rules: |
    -w /etc/passwd -p wa -k identity
   
- module: file_integrity
  paths:
  - /etc
 
- module: system
  datasets:
    - host
    - login
    - user
  period: 1m
  user.detect_password_changes: true

Коллектор создан, конфигурация тоже, пришло время воспользоваться возможностями по управлению конфигурациями и распространить изменения на все коллекторы, которые подключились к graylog.
Для этого нужно перейти в System / Sidecars / Administration, отметить все необходимые коллекторы (все auditbeat в нашем случае), нажать едва заметную серую ссылку "Configure" и выбрать из всплывшего списка подходящую конфигурацию.
После подтверждения начнется процесс деплоя конфигурации на все выбранные коллекторы.

Важное примечание: не забудьте создать input, который будет слушать на указанном в настройках порту (например 5044) иначе коллекторы данные отправлять то будут, но принять graylog их не сможет.

После завершения деплоя и успешного запуска сервисов должно получится примерно как на скриншоте:

Дашборды на десерт

Какие же данные в итоге предоставляет auditbeat?
- Очень много информации по аудиту безопасности и связанными с ним событиями.

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