В данной статье показан пример настройки GrayLog на CentOS 7

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

Разработчик рекомендует перед установкой спланировать ваш журнал событий. Для этого необходимо определиться с “стратегией” использования журналов, с тем какие логи необходимы, как собирать, кто будет иметь к ним доступ,  как и сколько хранить.

Стратегия использования журналов

Минимальная

“Делай то, что нужно”

Минимальная стратегия исходит из позиции  “Default No” при принятии решения, какие события собирать. Это означает, что вы не собираете никаких журналов если этого не требуется для определённого случая. Такая стратегия имеет ряд преимуществ снижает затраты на лицензирование и хранение за счёт уменьшения объёма собираемых событий. Такая стратегия также сводит к минимуму “шум”, создаваемый посторонними событиями, позволяя сосредоточиться на действительно важных. Наконец она повышает эффективность системы и запросов, производительность в целом.

Максимальная

“Собери всё и пусть Graylog сам отсортирует”

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

Виды применения

“Что вы хотите делать с данными логами?”

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

Источники журнала событий

“Какие журналы нужно собирать?”

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

Некоторые потенциальные источники событий по категориям.

Безопасность

• Брандмауэры
• Конечная точка безопасности (EDR, AV и т. Д.)
• Веб-Прокси / Шлюзы
• LDAP / Active Directory
• IDS
• DNS
• DHCP
• Серверы
• Рабочие станции
• Поток данных, передающихся по сети

Ops

• Приложения
• Сетевые устройства
• Серверы
• Захват пакетов / сетевой рекордер
• DNS
• DHCP
• Эл. адрес

DevOps

• Журналы приложений
• Журналы балансировки нагрузки
• Журналы системы автоматизации
• Бизнес Логика

Метод сбора

«Как вы будете собирать ?»

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

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

Graylog поддерживает множество типов ввода из коробки. На момент написания статьи Graylog поддерживает следующее:

• Syslog (TCP, UDP, AMQP, Kafka)
• GELF (TCP, UDP, AMQP, Kafka, HTTP)
• AWS (AWS Logs, FlowLogs, CloudTrail)
• Beats/Logstash
• CEF (TCP, UDP, AMQP, Kafka)
• JSON Path from HTTP API
• Netflow (UDP)
• Простой / не обработанный текст (TCP, UDP, AMQP, Kafka)

Пользователи

«Кто будет использовать решение?»

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

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

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

Типичные группы пользователей:

• Аналитики по безопасности
• Инженеры
• Менеджмент
• Справочная служба

Расчет требований к хранению

«Как долго вы будете хранить данные?»

Как и большинство хранилищ данных, Elasticsearch плохо реагирует, когда используется все доступное пространство. Чтобы такого не происходило, необходимо правильно планировать и контролировать.

Ключевой вопрос при планировании системы управления логами — сохранение журнала. Существует два способа сохранения данных журнала событий: онлайн или в архиве. Онлайн данные хранятся в Elasticsearch и доступны для поиска через графический интерфейс Graylog. Архивные данные хранятся в сжатом формате, либо на сервере Graylog, либо в общей сетевой папке. Он по-прежнему доступен для поиска, например, через GREP, но должен быть восстановлен в Graylog, чтобы его снова можно было найти через GUI.

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

Простое эмпирическое правило для планирования хранения — взять среднесуточную норму потребления, умножить ее на количество дней, в течение которых вам необходимо хранить данные в сети, а затем умножить это число на 1,3, чтобы учесть затраты метаданных. (ГБ / день х рет. Дней х 1,3 = требования к хранилищу).

Необходимые зависимости для сервера Graylog

После планирования приступим к непосредственной установки сервера.

Обратите внимание, что в этой статье мы используем CentOS 7 , поэтому на этапах установки показан менеджер пакетов Yum. Если вы используете какой-то другой дистрибутив, вы должны использовать менеджер пакетов вашего дистрибутива.

Основными компонентами для сервера Graylog являются:

• MongoDB : база данных.
• Elasticsearch : поисковая система и NoSQL-хранилище.
• GrayLog Server: анализатор, собирает логи из различных мест назначения.
• Graylog Web Interface: Веб-интерфейс с красивыми графиками.

Установка необходимых пакетов программ

Для начала устанавливаем openJDK. Так как Elasticsearch разработан на Java.

yum install java-1.8.0-openjdk-headless.x86_64 -y
yum install epel-release -y
yum install pwgen -y

Для этого нам понадобится добавить GPG ключ, используя следующую команду:

rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

Так как репозиторий Elasticsearch по умолчанию недоступен в CentOS 7/Rhel 7, необходимо создать файл repo вручную, включая следующие записи в файле репозитория Elasticsearch.

vi /etc/yum.repos.d/elasticsearch.repo

[elasticsearch-2.x]
name=Elasticsearch repository for 2.x packages
baseurl=https://packages.elastic.co/elasticsearch/2.x/centos
gpgcheck=1
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

Теперь можно установить Elasticsearch через yum:

yum install elasticsearch -y

После установки пакета Elasticsearch будет создан файл конфигурации esticsearch.yml, установите для имени кластера значение graylog, как показано ниже.

vi /etc/elasticsearch/elasticsearch.yml
cluster.name: graylog

Добавляем в автозагрузку elasticsearch  и запускаем сервис:

chkconfig elasticsearch on 
service elasticsearch start

После того, как вы включили elasticsearch.service ; Запустите команду curl:

curl -XGET 'http://localhost:9200/

Установка MongoDB

Далее добавляем репозиторий MongoDB с указанными ниже записями в repo-файле MongoDB, так как его по умолчанию тоже нет в Centos 7/Rhel 7.

vi /etc/yum.repos.d/mongodb-org-3.2.repo
[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc

 Устанавливаем пакет MongoDB

yum install mongodb-org -y

Добавляем mongod в автозагрузку и запускаем сервис:

chkconfig mongod on
service mongod start

Установка и настройка сервера Grylog

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

rpm -Uvh 

https://packages.graylog2.org/repo/packages/graylog-2.5-repository_latest.rpm

yum install graylog-server -y

Сгенерируйте секретный ключ:

pwgen -N 1 -s 96 

GXOy9t1L8gcMznE61d64AyadPicX8x9NMqwRPYDKTdqlSJvdBwk4v5hJI7WPkGeHiCiG6JoftdxeaCkE0icLa1C9cvcZxgqd

Задайте пароль для пользователя admin, он будет использован при входе веб-интерфейсе Graylog.

echo -n SomePassword | sha256sum

ca74e5fe75654735d3b8d04a7bdf5dcdd06f1c6c2a215171a24e5a9dcb28e7a2

В файле server.conf необходимо ввести секретный ключ и пароль для admin. Файл server.conf содержит исчерпывающую информацию по настройке каждой конфигурации и пример синтаксиса. Изучаем его и попутно устанавливаем необходимые параметры. Ниже привёл минимальный набор для запуска сервера.

vi /etc/graylog/server/server.conf

password_secret=GXOy9t1L8gcMznE61d64AyadPicX8x9NMqwRPYDKTdqlSJvdBwk4v5hJI7WPkGeHiCiG6JoftdxeaCkE0icLa1C9cvcZxgqd
root_password_sha2=ca74e5fe75654735d3b8d04a7bdf5dcdd06f1c6c2a215171a24e5a9dcb28e7a2
root_email = [email protected]
root_timezone=Europe/Moscow
elasticsearch_discovery_zen_ping_unicast_hosts = http://192.168.32.17:9300
elasticsearch_shards=1
rest_listen_uri = http://192.168.32.17:12900/
web_listen_uri = http://192.168.32.17:9000/

Теперь можно добавить Graylog в автозагрузку и запустить:

chkconfig --add graylog-server
systemctl daemon-reload
systemctl enable graylog-server.service
systemctl start graylog-server.service

Настройка портов firewall

Для работы Graylog необходимо открыть доступ к портам, которые мы указали в server.conf данные команды откроют доступ для портов 9000, 12900 и 1514:

firewall-cmd --permanent --zone=public --add-port=9000/tcp
firewall-cmd --permanent --zone=public --add-port=12900/tcp
firewall-cmd --permanent --zone=public --add-port=1514/tcp

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

firewall-cmd --reload

 Важно если у вас работает SElinux его необходимо соответствующе настроить. Так как на моей ОС он выключен я пропущу данный шаг.

Доступ к веб-интерфейсу Graylog

Запустите веб-браузер на своем устройстве и введите URL-адрес сервера Graylog http://192.168.32.17:9000/ . Вы будете перенаправлены на следующую страницу.

 Чтобы войти в веб-интерфейс, введите имя пользователя admin и пароль – (тот самый пароль который мы шифровали, естественно в обычной форме ).

Теперь вы можете настроить его в соответствии со своими требованиями. Надеюсь вы составили свою стратегию использования журналов.