Открытое решение Graylog. Cбор и анализ событий в сетях промышленных масштабов::Журнал СА 03.2019
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 975
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1098
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 829
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 664
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1265
Комментарии: 0
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2019 / Выпуск №03 (196) / Открытое решение Graylog. Cбор и анализ событий в сетях промышленных масштабов

Рубрика: Администрирование /  Инструменты

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

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

Открытое решение 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. При добавлении источника данных, необходимо выбрать один из предопределенных типов

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

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

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

Рисунок 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. При выполнении определенных условий для потока входящих сообщений можно сгенерировать соответствующее оповещение

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

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

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

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

Рисунок 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.


Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru