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

27 октября, 2020 12:36 пп 613 views | Комментариев нет

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

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

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

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

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

Требования

  • Два сервера Debian 10, настроенные согласно этому мануалу. Не забудьте включить брандмауэр 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 и используем ее для регистрации сертификатов. Также эта утилита автоматически обновит сертификаты по истечении срока их действия. В нашем случае процесс регистрации сертификатов на клиенте и сервере одинаков. Вам нужно только указать правильное имя хоста, на котором вы запускаете команду регистрации.

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

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

Теперь, когда вы установили 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: , , ,

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