Централизация логов с помощью Journald в Ubuntu 20.04

20 октября, 2020 12:05 пп 1 037 views | Комментариев нет

| | Комментировать запись

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

Средства централизованного логирования имеют ряд преимуществ по сравнению с индивидуальным хранением логов на каждом хосте:

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

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

Требования

  • Два сервера Ubuntu 20.04, настроенные согласно этому мануалу. Не забудьте включить брандмауэр UFW на обоих серверах.
  • Два имени хоста, направленные на ваши машины. Одно имя предназначено для клиента, который генерирует логи, а второе имя – для сервера, который централизованно хранит логи. В этом мануале мы будем использовать условные имена хостов client.your_domain и server.your_domain соответственно.

В отдельных терминалах войдите на обе машины через SSH как пользователь sudo.

Примечание: Некоторые команды нужно запускать на обеих машинах, другие – только на сервере или только на клиенте. В течение всего мануала блоки команд будут помечены соответствующим образом.

1: Установка systemd-journal-remote

Сейчас мы установим пакет systemd-journal-remote на клиенте и сервере. Этот пакет содержит компоненты, которые клиент и сервер будут использовать для передачи сообщений логов.

Сначала запустите обновление системы:

# клиент и сервер
sudo apt update
sudo apt upgrade

Затем установите пакет systemd-journal-remote:

# клиент и сервер
sudo apt install systemd-journal-remote

Перейдите на сервер, а затем включите и запустите два компонента systemd, которые необходимы для получения сообщений логов:

# сервер
sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl enable systemd-journal-remote.service

Параметр –now в первой команде запускает сервисы немедленно. Мы не использовали его во второй команде, потому что этот сервис не запустится, пока у него не будет сертификатов TLS, которые мы создадим позже.

На клиенте включите компонент, который systemd использует для отправки сообщений логов на сервер:

# клиент
sudo systemctl enable systemd-journal-upload.service

Затем на сервере откройте в UFW порты 19532 и 80. Это позволит серверу получать сообщения логов от клиента. Порт 80 certbot будет использовать для создания сертификата TLS. Следующие команды откроют эти порты:

# сервер
sudo ufw allow in 19532/tcp
sudo ufw allow in 80/tcp

На клиенте нужно открыть только порт 80:

# клиент
sudo ufw allow in 80/tcp

Итак, мы установили необходимые компоненты и выполнили базовую настройку системы на клиенте и на сервере. Прежде чем настроить эти компоненты для передачи логов, давайте получим TLS сертификаты Let’s Encrypt для клиента и сервера с помощью утилиты certbot.

2: Установка Certbot и регистрация сертификатов

Let’s Encrypt – это центр сертификации, который выдает бесплатные сертификаты TLS. Эти сертификаты позволяют компьютерам шифровать данные, которые они передают между собой, а также проверять подлинность друг друга. Эти сертификаты позволяют защитить ваши данные в Интернете с помощью HTTPS. Такие сертификаты могут использоваться любым другим приложением, которому нужен такой же уровень безопасности. Процесс регистрации сертификатов одинаков, независимо от того, для чего вы их используете.

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

Сначала включите репозиторий universe, поскольку утилита certbot находится в этом репозитории Ubuntu.

Примечание: Если даже у вас уже включен universe, выполнение этих команд не повлияет на вашу систему, их можно спокойно запускать.

# клиент и сервер
sudo apt install software-properties-common
sudo add-apt-repository universe
sudo apt update

Установите certbot на оба хоста:

# клиент и сервер
sudo apt install certbot

Теперь, когда вы установили certbot, выполните следующую команду, чтобы зарегистрировать сертификаты на клиенте и сервере:

# клиент и сервер
sudo certbot certonly --standalone --agree-tos --email 8host@your_domain -d your_domain

В этой команде мы использовали следующие параметры:

  • certonly: зарегистрирует сертификат, не внося никаких других изменений в систему.
  • –standalone: ​​использует встроенный веб-сервер certbot для проверки запроса сертификата.
  • –agree-tos: автоматически принимает условия использования Let’s Encrypt.
  • –email your_email: это адрес электронной почты, который Let’s Encrypt будет использовать для отправки уведомлений об истечении срока действия сертификата и другой важной информации.
  • -d your_domain: имя хоста, для которого предназначен сертификат. Это значение должно соответствовать системе, в которой вы его запускаете.

Когда вы запустите эту команду, она спросит, хотите ли вы поделиться адресом электронной почты с Let’s Encrypt, чтобы ЦС мог отправлять вам новости и другую информацию о своей работе. Это необязательно. Если вы решите не делиться своим адресом, регистрация сертификата все равно пройдет в обычном режиме.

Когда процесс регистрации сертификата завершится, файлы сертификата и ключей будут помещены в /etc/letsencrypt/live/your_domain/ (где your_domain – это имя хоста, для которого вы зарегистрировали сертификат).

После этого нужно загрузить копию сертификата ЦС Let’s Encrypt и промежуточных сертификатов и поместить их в один файл. journald будет использовать этот файл для проверки подлинности сертификатов на клиенте и сервере при их взаимодействии.

Следующая команда загрузит два сертификата с веб-сайта Let’s Encrypt и поместит их в один файл под названием letsencrypt-comdated-certs.pem в домашнем каталоге вашего пользователя.

Выполните эту команду на клиенте и сервере, чтобы загрузить сертификаты и создать объединенный файл:

# клиент и сервер
curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

Затем переместите этот файл в каталог Let’s Encrypt, содержащий сертификаты и ключи:

# клиент и сервер
sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

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

3: Настройка сервера

Примечание: Все команды данного раздела следует выполнить только на сервере.

Сейчас вы настроите сервер для поддержки сертификатов и ключей, которые вы создали только что, чтобы он мог начать принимать логи от клиента.

systemd-journal-remote – это компонент, который прослушивает сообщения логов. Откройте конфигурационный файл /etc/systemd/journal-remote.conf с помощью текстового редактора, чтобы начать настройку:

sudo nano /etc/systemd/journal-remote.conf

Затем раскомментируйте все строки в разделе [Remote] и установите пути, указывающие на только что созданные файлы TLS:

[Remote] Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

Здесь мы использовали следующие опции:

  • Seal=false: подписывает данные в журнале. Включите этот параметр, если вам нужна максимальная безопасность; в противном случае можете оставить значение false.
  • SplitMode=host: логи удаленных клиентов будут разделены по хостам в /var/log/journal/remote. Если вы предпочитаете, чтобы все логи собирались в один файл, установите значение SplitMode=false.
  • ServerKeyFile: файл закрытого ключа сервера.
  • ServerCertificateFile: файл сертификата сервера.
  • TrustedCertificateFile: файл, содержащий сертификаты ЦС Let’s Encrypt.

Теперь вам нужно изменить права доступа к каталогам Let’s Encrypt, которые содержат сертификаты и ключ, чтобы systemd-journal-remote мог их читать и использовать.

Сначала измените привилегии, чтобы сертификат и закрытый ключ были доступны для чтения:

sudo chmod 0755 /etc/letsencrypt/{live,archive}
sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

Читайте также: Привилегии в Linux: что это и как с этим работать

Затем сделайте группу systemd-journal-remote владельцем закрытого ключа:

sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

Теперь вы можете запустить systemd-journal-remote:

sudo systemctl start systemd-journal-remote.service

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

4: Настройка клиента

Примечание: Все команды данного раздела следует выполнить только на клиенте.

Сейчас мы настроим компонент, который будет передавать сообщения логов с клиента на сервер. Этот компонент называется systemd-journal-upload.

Согласно стандартной конфигурации, systemd-journal-upload использует временного пользователя, который существует только во время выполнения процесса. Это усложняет чтение сертификатов и ключей TLS для systemd-journal-upload. Чтобы решить эту проблему, давайте создадим постоянного системного пользователя с тем же именем, что и у временного пользователя.

Сначала создайте нового пользователя systemd-journal-upload с помощью команды adduser:

sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

Давайте рассмотрим параметры команды:

  • –system: создает нового системного пользователя. Она присваивает пользователю UID (идентификатор пользователя) ниже 1000. UID выше 1000 обычно присваивается учетным записям пользователей, которые человек будет использовать для входа в систему.
  • –home /run/systemd: установит /run/systemd в качестве домашнего каталога для этого пользователя.
  • –no-create-home: отключает создание набора домашних каталогов, поскольку он уже существует.
  • –disabled-login: отключает вход в систему для этого пользователя (например, через SSH).
  • –group: создает одноименную группу для этого пользователя.

Затем установите привилегии и права собственности на сертификаты Let’s Encrypt:

sudo chmod 0755 /etc/letsencrypt/{live,archive}
sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

Теперь отредактируйте конфигурацию для systemd-journal-upload, которая находится в /etc/systemd/journal-upload.conf. Откройте этот файл в текстовом редакторе:

sudo nano /etc/systemd/journal-upload.conf

Отредактируйте этот файл так, чтобы он выглядел следующим образом:

[Upload] URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

Перезапустите сервис systemd-journal-upload, чтобы он использовал новую конфигурацию:

sudo systemctl restart systemd-journal-upload.service

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

5: Тестирование клиента и сервера

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

Сервер логирования хранит данные клиентов в каталоге /var/log/journal/remote/. Когда вы перезапустили клиент в конце последнего раздела, он начал отправлять сообщения логов, поэтому теперь файл лога находится в /var/log/journal/remote/. Имя файла должно совпадать с именем хоста, которое вы использовали для сертификата TLS.

Используйте команду ls, чтобы убедиться, что лог клиента находится на сервере:

# сервер
sudo ls -la /var/log/journal/remote/

На экране появится такой результат:

total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

Затем создайте сообщение лога на клиенте, чтобы убедиться, что сервер зарегистрирует его. Используйте утилиту logger для создания пользовательского сообщения на клиенте. Если все работает, systemd-journal-upload передаст это сообщение на сервер.

На клиенте выполните следующую команду регистратора:

# клиент
sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

Параметр -p syslog.debug в этой команде устанавливает субъекта и уровень важности сообщения. Указывая syslog.debug, вы отправляете тестовое сообщение. Эта команда запишет сообщение ### TEST MESSAGE from client.your_domain ### в лог клиента, которое systemd-journal-upload затем передаст на сервер.

Затем просмотрите лог клиента на сервере, чтобы убедиться, что сообщения записываются правильно. Это собой двоичный файл лога, поэтому вы не сможете прочитать его с помощью таких инструментов, как less. Это можно сделать с помощью journalctl с параметром –file=, который позволяет указать нужный файл лога:

# сервер
sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

Вы увидите ваше сообщение:

. . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

Ваш сервер централизации логов теперь успешно собирает данные из клиентской системы.

Заключение

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

Tags: , , , ,

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