ДЕНИС СИЛАКОВ, к.ф.-м.н., старший системный архитектор,Virtuozzo, доцент, Национальный исследовательский университет «Высшая школа экономики», dsilakov@virtuozzo.com

Открытое решение Graylog
Cбор и анализ событий в сетях промышленных масштабов

Задача сбора и анализа всевозможных журналов с множества машин в подконтрольной системному администратору сети существует столько же, сколько компьютерные сети как таковые. За это время заметно эволюционировали (и революционно выросли в объеме) как сами собираемые данные, так и инструменты сбора

Проверенные временем программы типа rsyslog и syslog-ng по-прежнему популярны, однако сами по себе они уже не удовлетворяют всех потребностей (в первую очередь в плане анализа данных) и часто используются как компоненты более сложной инфраструктуры.

Одним из примеров подобных комплексных решений является Graylog – инструментарий централизованного сбора, хранения и анализа данных о различных событиях на серверах локальной сети.

В данной статье мы с вами рассмотрим стабильную ветку Graylog 2.x и последнюю версию из этой ветки 2.5.1.

Параллельно развивается ветка 3.x, но на данный момент она рекомендуется только для использования энтузиастами.

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

Установка

Graylog предлагает множество вариантов установки:

• пакеты для CentOS 6/7, Debian 7/8/9, Ubuntu и производных;
• скрипты развертывания с помощью Chef, Puppet, Ansible и файлы для Vagrant;
• готовые образы виртуальных окружений для Open-Stack, EC2, Docker и любых средств виртуализации, понимающих формат OVA;
• наконец, можно просто скачать архив с файлами приложения и развернуть его на любой системе согласно инструкциям.

Установка с помощью образа ВМ наиболее проста (например, для знакомства мы изначально ставили Graylog в виртуальную машину Virtuozzo Infrastructure Platform), однако не рекомендуется к реальному использованию – мощностей ВМ может и не хватить для обработки реальных данных. Поэтому в данной статье мы рассмотрим установку Graylog из пакетов RPM на машине под управлением Virtuozzo 7 – для нее вполне подойдут пакеты от CentOS.

Перед установкой самого Graylog, необходимо установить необходимые ему компоненты: Java, MongoDB и Elasticsearch. Первую можно поставить из репозиториев системы, а другие – непосредственно из репозиториев производителей:

# yum install java-1.8.0-openjdk
# yum install https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-server-4.0.5-1.el7.x86_64.rpm
# yum install https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.4.rpm

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

В большинстве случаев эти сервисы MongoDB и Elasticsearch в дополнительной настройке не нуждаются, можно их сразу запустить и добавить в список сервисов, включаемых при старте системы:

# systemctl enable mongod elasticsearch
# systemctl start mongod elasticsearch

Больше мы к этим сервисам возвращаться не будем, желающих же детальнее узнать про Elasticsearch отправим к статье [1].

Для установки сервера graylog, необходимо сначала добавить репозиторий посредством установки пакета graylog-2.5-repository_latest, а затем уже поставить сам пакет graylog-server:

# rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-2.5-repository_latest.rpm
# yum install graylog-server

Обратите внимание, что в рамках ветки 2.5 вы сможете обновлять пакеты graylog с помощью стандартной команды yum update, однако для перехода даже на ветку 2.6 (если такая появится) либо 3.0 надо будет подключать отдельные репозитории и следовать инструкциям по обновлению, поскольку такой переход может потребовать ручной адаптации конфигурационных файлов.

После установки пакетов необходимо внести правки в файл конфигурации /etc/graylog/server/server.conf – в варианте по умолчанию он работать не будет.

В частности, необходимо заполнить поля password_secret («соль», которая будет использоваться при шифровании паролей пользователей) и root_password_sha2 – хеш-сумма пароля для входа в веб-интерфейс под пользователем admin.

Хеш-сумму пароля необходимо вычислить с помощью sha256sum:

# echo -n "ваш_пароль" | sha256sum

А password_secret рекомендуется сгенерировать с помощью утилиты pwgen – его длина должна составлять как минимум 64 символа:

# pwgen -N 1 -s 64

Также есть смысл настроить параметры rest_listen_uri и web_listen_uri, чтобы иметь возможность заходить в веб-интерфейс и использовать API с других машин – по умолчанию эти параметры выставлены в «127.0.0.1».

Опционально можно указать сертификат для доступа к веб-интерфейсу и API по протоколу https.

Когда все настройки завершены, можно включать и запускать сервис graylog-server:

# systemctl enable graylog-server
# systemctl start graylog-server

Спустя непродолжительное время на указанном вами в файле конфигурации адресе на порту 9000 (если вы не изменили его в конфигурации) станет доступен веб-интерфейс Graylog.

Если этого не случилось – загляните в файл /var/log/graylog-server/server.log, в котором Graylog сообщает обо всех неполадках.

Если же все прошло успешно, то можно начинать работу по настройке сбора данных с ваших серверов.

Настраиваем сбор журналов

Для первого входа в веб-интерфейс Graylog используйте пользователя admin и пароль, хеш-сумму которого вы указали в файле конфигурации. В дальнейшем в меню System можно создать новых пользователей во внутренней базе Graylog, настроить интеграцию с LDAP, Active Directory и другими внешними механизмами аутентификации.

Для начала же перейдем к непосредственным обязанностям сервиса и настроим извлечение логов rsyslog по протоколу TCP с одной из Linux-машин под управлением Virtuozzo.

Первым делом необходимо настроить сам rsyslog для передачи данных в Graylog. Делается это созданием нового файла в директории /etc/rsyslog.d со следующей строкой:

*.* @@адрес_сервера_graylog:514;RSYSLOG_SyslogProtocol23Format

Надо также убедиться, что порт 514 на сервере Graylog доступен с этой машины. Кроме того, порт должен быть доступен самому Graylog, который работает с правами непривилегированного пользователя и по умолчанию не имеет доступа к портам диапазона от 1 до 1024. Решить эту ситуацию можно перенаправлением данных на сервере Graylog с порта 514 на непривилегированный порт, например 1514:

# iptables -t nat -A PREROUTING -p tcp --dport 514 -j REDIRECT --to 1514

После этого можно возвращаться в веб-интерфейс Graylog и переходить в меню System → Inputs, где настраиваются источники входящих данных. При создании нового источника необходимо выбрать его тип – набор доступных возможностей впечатляет (и может расширяться с помощью плагинов), нас в данный момент интересует Syslog TCP (см. рис. 1).

Рисунок 1. При добавлении источника данных, необходимо выбрать один из предопределенных типов

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

После сохранения настроек можно нажимать кнопку Launch new input для активации источника – если Graylog сможет получить данные, новый источник перейдет в состояние Running и вы увидите статистику получаемых данных (см. рис. 2).

Рисунок 2. Для каждого источника можно посмотреть статистику данных и просмотреть все сообщения

На этой же странице можно перейти к просмотру всех полученных от источника сообщений, нажав кнопку Show received messages.

Поиск и анализ данных

Кнопка показа сообщений от источника ведет на страницу поиска и фильтрации сообщений. Возможности поискового механизма очень богаты и подробно описаны в документации [2], при переходе же со страницы источника поиск уже настроен на отображение сообщений только от него.

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

Более точно: на вкладку Dashboards можно вынести информацию об общем количестве сообщений, удовлетворяющих выбранному критерию (кликнув на кнопку Add count to dashboard), а также график интенсивности получения сообщений во времени (кнопка Add to dashboard в правом верхнем углу соответствующей гистограммы).

В итоге на панелях Dashboards вы сможете оперативно отслеживать сразу множество интересных вам различных показателей.

Сообщения в Graylog не просто отображаются «как есть», но подвергаются дополнительному анализу – из них по возможности извлекаются имя пославшей сообщение программы, степень критичности и ряд других типичных показателей. На основе этих характеристик можно производить дополнительную фильтрацию – например, отображать только сообщения заданной программы либо только критические ошибки.

Graylog хорошо справляется с подобным разбором стандартных сообщений от того же rsyslog, а для нестандартных данных предлагает настроить свои собственные анализаторы.

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

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

В окне создания анализатора вам предложат сразу посмотреть на результат применения вашего экстрактора к произвольной строке.

Graylog умеет самостоятельно разбирать ряд типичных сообщений – например, строк в формате переменная=значение или сообщений в формате JSON – и сохранять их элементы в поля с соответствующими названиями.

Например, если в вашем сообщении есть следующая JSON-строка:

{"error": {"severity": "critical", "message": "crash"}}

то Graylog превратит ее в два поля, error_severity и error_message, со значениями critical и crash соответственно.

Потоки сообщений и нотификации

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

Для фильтрации сообщений Graylog предоставляет механизм потоков (Streams), создание и настройка которых доступны в одноименном пункте главного меню веб-интерфейса. Каждый поток содержит сообщения, удовлетворяющие определенному критерию – как правило, используется фильтрация по ключевым словам.

По умолчанию в Graylog уже создан один поток – All messages, – содержащий все входящие сообщения. Наличие хотя бы одного потока необходимо, поскольку именно к ним привязываются механизмы оповещения (Alerts) системных администраторов об интересующих их событиях. Настраиваются оповещения в меню Alerts, и для каждого из них надо определить поток анализируемых сообщений и условие срабатывания.

Типичными условиями является появление сообщений с заданным текстом либо слишком частое повторение некоторых сообщений в течение определенного промежутка времени. Для примера настроим оповещение на случай, когда сообщений просто становится слишком много. Для этого при создании Alert укажем All messages в качестве потока и Message Count Alert Condition в роли условия.

После нажатия кнопки Add alert condition зададим конкретные условия (см. рис. 3) – период времени (в минутах), количество сообщений и Grace period – время бездействия после того, как условие генерации оповещения перестало быть истинным.

Рисунок 3. При выполнении определенных условий для потока входящих сообщений можно сгенерировать соответствующее оповещение

Механизм работы данного примера следующий: если в течение минуты мы получаем более 10 сообщений, то генерируется оповещение. Если в течение следующих десяти минут число сообщений нормализуется, то инцидент с превышением числа сообщений помечается как «разрешенный» (Resolved), если нет – то генерируется новое оповещение. Если бы мы выставили ненулевой Grace period, то Graylog дополнительно выжидал бы указанное время после разрешения инцидента перед новым анализом.

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

После этого имеет смысл протестировать наше оповещение и сгенерировать на подконтрольных машинах относительно большое количество сообщений – хотя бы десяток за минуту. На вкладке Alerts overview должен появиться новый инцидент в состоянии Unresolved (см. рис. 4).

Рисунок 4. Если условие срабатывания оповещения перестает выполняться, то соответствующий инцидент переходит в состояние

После того как поток сообщений прекратится, инцидент перейдет в состояние Resolved.

Агенты Graylog

В примере с syslog мы настроили сам сервис на отсылку журналов на сервер Graylog. Однако далеко не все сообщения от ОС и приложений можно перенаправить таким образом, ведь многие программы просто записывают свои журналы в локальные файлы и не предусматривают возможности их отсылки куда-то еще штатными средствами.

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

Агент состоит из двух частей – сервиса Graylog Collector Sidecar, общающегося с сервером (получающим от него параметры для сбора данных и отправляющим обратно собранную информацию) и бэкенда, непосредственно анализирующего файлы журналов системы. На данный момент пакеты агентов не входят в репозиториий graylog и необходимо их скачивать и устанавливать вручную с репозиториев github [3].

Начнем с Sidecar. На сайте имеются пакеты collector-sidecar в форматах deb и rpm, пригодные для установки в Debian, Ubuntu, CentOS и производных (в том числе для Virtuozzo 7). Для Windows предоставляется установщик collector_sidecar_installer.exe, который может работать как в интерактивном, так и в автоматическом режиме (параметр /S).

После установки sidecar необходимо отредактировать файл /etc/graylog/collector-sidecar/collector_sidecar.yml (для Windows – C:\Program Files\graylog\collector-sidecar\collector_sidecar.yml) – как минимум надо указать адрес вашего сервера Graylog и тэги, по которым надо выбирать конфигурацию сбора логов (об этом – чуть ниже).

В этом же файле осуществляется включение того или иного бэкенда – достаточно найти нужный в секции backends и выставить флаг enabled в true (а выставление флага в false бэкенд отключит).

Можно также разрешить отсылку на сервер метрик машины (send_status), включающих в себя некоторые характеристики системы типа использования диска и выставленные для sidecar тэги, а также периодическую отсылку листинга директорий машины (list_log_files). С помощью такой информации в веб-интерфейсе Graylog можно будет смотреть, какие файлы журналов доступны для агентов.

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

Чтобы sidecar запускался как демон, необходимо установить и включить соответствующий сервис. В Virtuozzo и дистрибутивах Linux с systemd это делается следующими командами:

# graylog-collector-sidecar -service install
# systemctl start collector-sidecar
# systemctl enable collector-sidecar

Для Windows:

$ "C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe" -service install
$ "C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe" -service start

Бэкенды Filebeat и Winlogeventbeat входят непосредственно в пакет collector-sidecar, nxlog же следует ставить отдельно c официального сайта [4]. При этом после установки необходимо отключить автоматический запуск сервиса nxlog – за его запуск и останов будет отвечать sidecar, отвечающий за перезапуск процессов сбора данных при любом изменении конфигурации, получаемой от сервера.

Сбор данных от агентов

Перед регистрацией агентов в Graylog необходимо в веб-интерфейсе зарегистрировать соответствующий источник данных (Input), в который агенты смогут посылать информацию.

При использовании Filebeat или Winlogeventbeat можно использовать тип источника Beats, для NXlog доступен только GELF (Graylog Extended Log Format) – собственный формат Graylog, созданный «по мотивам» syslog, но не имеющий его ограничений (в первую очередь на длину сообщения).

После создания источника можно идти в секцию System → Collectors → Manage Configurations для настройки конфигурации – правил сбора данных. Здесь при создании новой конфигурации сразу нужно выбрать вкладку, соответствующую бэкенду, который вы планируете использовать.

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

Далее в секции Output надо определить, куда отправлять данные (как правило, это сервер Graylog; однако вы можете развернуть несколько машин с Graylog с балансировкой нагрузки между ними – в таком случае здесь надо указать адрес балансировщика). Здесь же можно настроить разбор записей и формирование полей (фактически экстрактор).

Наконец, в секции Inputs задаются данные, которые необходимо собирать – как правило, это всевозможные файлы журналов. Веб-интерфейс позволяет в удобном виде задать наиболее популярные характеристики сбора информации (пути к журналам, время отсылки и так далее) и Graylog сам сгенерирует файл конфигурации бэкенда на основе этих данных. Однако вы можете указать непосредственно содержимое файла или его часть в поле snippet – это поле добавляется в генерируемый файл без изменений.

На этом все. Теперь агенты на подконтрольных машинах смогут найти конфигурацию по указанному тэгу и начать посылать данные.

В этой статье мы рассмотрели базовые сценарии использования Graylog. Установить и начать его применять несложно. При этом за внешней простотой скрываются гибкость настройки, мощные возможности фильтрации и анализа информации, а также производительность, позволяющая ежедневно обрабатывать терабайты данных. Освоиться со всем этим богатством поможет подробная и всеобъемлющая документация [2], к которой мы и отправляем всех заинтересовавшихся возможностями открытого инструмента, превосходящего многие коммерческие аналоги.

1. Яремчук С. Настраиваем стек ELK для централизованного хранения журналов. // «Системный администратор», № 1-2, 2018 г. – С. 16-22. URL: http://samag.ru/archive/article/3575.
2. Документация Graylog – http://docs.graylog.org.
3. Репозиторий Graylog Sidecar – https://github.com/Graylog2/collector-sidecar/releases.
4. Официальный сайт NXlog – https://nxlog.co.

Ключевые слова: syslog, graylog, журналы, security.

Комментарии могут оставлять только зарегистрированные пользователи