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

Автор выбрал фонд Free and Open Source Fund для получения пожертвования в рамках программы Write for DOnations.

Введение

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

Централизованный сервер управления журналами дает ряд преимуществ по сравнению с хранением журналов на каждом хосте:

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

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

Предварительные требования

Для прохождения этого обучающего руководства вам потребуется следующее:

• Два сервера Debian 10.
• Пользователь без прав root с привилегиями sudo на обоих серверах. Инструкции можно найти в руководстве «Начальная настройка сервера с Debian 10». Также вам следует настроить брандмауэр UFW на обоих серверах, как объясняется в этом руководстве.
• Два хоста, указывающие на ваши серверы. Одно имя хоста для клиентской системы, которая генерирует журналы, и другое — для сервера сбора журналов. Узнайте, как назначать имена хостов для дроплетов DigitalOcean, ознакомившись с документацией по доменам и DNS.

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

• client.your_domain: клиентская система, генерирующая журналы.
• server.your_domain: сервер хранения журналов.

Для начала этого обучающего модуля выполните вход на клиент и на сервер в отдельных терминалах через SSH как пользователь без прав root с привилегиями sudo.

Шаг 1 — Установка systemd-journal-remote

На этом шаге мы установим пакет systemd-journal-remote на серверах client и server. Этот пакет содержит компоненты, которые client и server используют для пересылки сообщений журнала.

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

sudo apt update
sudo apt upgrade

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

sudo apt install systemd-journal-remote

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

sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl enable systemd-journal-remote.service

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

Активируйте на сервере client компонент, используемый systemd для отправки сообщений журнала на сервер:

sudo systemctl enable systemd-journal-upload.service

Откройте на сервере порты 19532 и 80 в брандмауэре UFW. Это позволит серверу получать сообщения журнала от клиента. Порт 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 для серверов client и server с помощью утилиты certbot.

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

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

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

Вначале установите certbot и утилиту curl на обоих хостах:

sudo apt install certbot curl

После установки certbot запустите следующую команду для регистрации сертификатов на клиенте и на сервере:

sudo certbot certonly --standalone --agree-tos --email sammy@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-combined-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

Затем измените группового владельца закрытого ключа на группу 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 по умолчанию используется временный пользователь, существующий только во время выполнения процесса. Это усложняет предоставление systemd-journal-upload разрешения на чтение сертификатов TLS и ключей. Для устранения этой проблемы необходимо создать нового пользователя системы с тем же именем, что и у временного пользователя, который будет использоваться вместо него.

Вначале создайте нового пользователя 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/

Эта команда выводит содержимое каталога, показывая файл журнала:

Output
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 перешлет это сообщение на сервер.

Запустите на клиенте следующую команду logger:

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

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

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

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

Заключение

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