Одним из важных компонентов в системах Linux являются системные журналы работы. Они наполняются важной информацией о работе системы, ее состоянии, наличии ошибок, критических сбоях, состоянии безопасности. Системы Linux, как правило, хранят журналы локально. Но такой метод совершенно не пригоден для кластерных систем. Для этого целесообразней использовать централизованный сервер журналирования, на который каждый сервер (хост) Linux будет пересылать свои данные в реальном времени. Централизованное администрирование экономит дисковое пространство на серверах, т.к. логирование переносится на специально отведенный сервер. Соответственно дисковое пространство на центральном сервере должно быть большей емкости. Журналы логирования централизованы, а значит доступ к ним предоставляется определенному кругу лиц из числа ИТ персонала, которые не могут войти напрямую на сервера из соображений безопасности. Рассмотрим, как централизовать логи с помощью Journald в Ubuntu 20.04. Нам необходимо произвести установку и настройку этого компонента как на клиентской, так и на серверной части оборудования.
Для осуществления поставленной цели необходимо иметь два настроенных хоста Ubuntu 20.04 (конфигурцаию будем производить со включенным брандмауэром UFW на обоих хостах).
И так начнем. Зайдем на наши настроенные хосты под Ubuntu 20.04 под разными терминальными сессиями через SSH. Присвоим условные имена server.domain (далее сервер) и client.domain (далее клиент).
Устанавливаем systemd-journal-remote
Необходимо уставить пакет systemd-journal-remote на наших хостах. В нем содержатся все те компоненты, которые будут использованы для передачи информации о работе оборудования.
Обновим систему на client.domain и на server.domain:
$ sudo apt update $ sudo apt upgrade
Этот пакет systemd-journal-remote необходимо инсталлировать на client.domain и server.domain:
$ sudo apt install systemd-journal-remote
После установки пакета, необходимо включить и запустить некоторые основные компоненты systemd, нужные для полноценной централизованной работы сервера журналирования:
$ sudo systemctl enable --now systemd-journal-remote.socket $ sudo systemctl enable systemd-journal-remote.service
Первая команда с параметром now запускает службу systemd-journal-remote.socket немедленно.
Во второй команде этот параметр мы использовать не будет, так как для запуска службы необходимы сертификаты TLS, позволяющие шифровать поток данных, передаваемые через не защищенные сети. Сертификатами мы займемся чуть позже.
Теперь на клиенте после установки необходимо включить компонент systemd, необходимый для передачи лог-журналов на сервер централизации.
$ sudo systemctl enable systemd-journal-upload.service
Далее, нам необходимо на сервере server.domain открыть порты 80 и 19532 в UFW для получения логов от клиента client.domain. Порт 80 используются для формирования 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.domain и server.domain. Используем утилиту Certbot.
Устанавливаем Certbot
Let’s Encrypt — это ЦС, предназначенный для выдачи бесплатных TLS-сертификатов. Сертификаты позволят нашим хостам шифровать трафик и проверять подлинность друг друга и осуществлять защиту данных по средствам протокола HTTPS.
Сервис Certbot позволяет регистрировать сертификаты, обновляет их по истечении сроков действия. Регистрировать сертификаты мы будет на каждом из наших хостов. Именование хоста при регистрации должно соответствовать действенному имени узла, на котором проходит регистрация.
Для установки Certbot будем использовать так называемые snap пакеты. Для этого, и на server.domain, и на client.domain нужно установить snap:
$sudo apt update$sudo apt install snapd
Установку Certbot также осуществляем на обоих наших хостах:
$ sudo snap install --classic certbot
И ещё одной командой необходимо подготовить установленный пакет к работе:
$ sudo ln -s /snap/bin/certbot /usr/bin/certbot
После установки Certbot, производим регистрацию сертификатов на наших хостах. Используем следующую команду:
$ sudo certbot certonly --standalone --agree-tos --email my_email@my_domain -d my_domain
Параметры в команде означают следующее:
certonly: регистрация сертификата без изменений.standalone: проверка запроса встроенным сервером Certbot.agree-tos: соглашение с условиями Let’s Encrypt.my_email@my_domain: электронная почта для получения необходимых служебных уведомлений.my_domain: именование узла, для которого выделяется TLS-сертификат. Это значение должно соответствовать системе, в которой запускается команда.
После завершения процесса регистрации сертификата, файлы будут располагаться в каталоге /etc/letsencrypt/live/domain/ (где domain – имя узла, который зарегистрирован в сертификате).
Устанавливаем сертификат
Для проверки подлинности сертификатов наших хостов, необходимо загрузить файлы ЦС Let’s Encrypt. После загрузки, поместим их в один файл, который будет осуществлять проверку подлинности сертификатов наших хостов при передачи лог-информации от клиента серверу.
Загрузим сертификаты с веб-сайта Let’s Encrypt и запишем в один файл letsencrypt-comdated-certs.pem. Располагаться он будет в каталоге /home:
$ 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/domain/
На этом этапе регистрация необходимых сертификатов и ключей завершена. Теперь необходимо произвести настройки основного сервера, на котором осуществляется централизованный сбор и хранение лог-журналов, чтобы он мог работать с нашим клиентом.
Приступим к настройке сервера
Чтобы наш сервер начал получать лог-журналы от клиентского хоста, необходимо настроить поддержку сертификатов и ключей.
systemd-journal-remote — это компонент, который слушает сообщения логов. Внесем некоторые изменения в файл конфигурации /etc/systemd/journal-remote.conf:
$ sudo nano /etc/systemd/journal-remote.conf
Необходимо снять комментарий со всех строк в разделе [Remote] и указать соответствующие пути на каталог размещения TLS-сертификатов:
Немного конкретики по используемым опциям:
Seal=false: отвечает за идентификацию данных в лог-журнале. Включение данного параметра обеспечивает максимальную безопасность, иначе можно использовать ключfalse;SplitMode=host: лог-журналы будут храниться раздельно по каждому хосту в/var/log/journal/remote. Иначе можно использовать значениеfalse, чтобы все логи собирались в один файл;ServerKeyFile: каталог, в котором расположен файл закрытого ключа сервера централизации;ServerCertificateFile: директория, в которой расположен файл сертификата сервера централизации;TrustedCertificateFile: каталог, в котором содержатся сертификаты Let’s Encrypt.
Выйдем из редактирования конфигурационного файла с сохранением.
Предоставить сервису systemd-journal-remote права, для осуществления необходимого функционала. Разрешим чтение и выполнение:
$ sudo chmod 0755 /etc/letsencrypt/{live,archive}
– эти права дают возможность пользователю читать и запускать на выполнение, владелец может редактировать;
$ sudo chmod 0640 /etc/letsencrypt/live/server.domain/privkey.pem
– эти права дают возможность владельцу чтения и записи, группе только чтение.
Назначим группе systemd-journal-remote права на владение закрытым ключом:
$ sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.domain/privkey.pem
Теперь запустим службу на сервере systemd-journal-remote:
$ sudo systemctl start systemd-journal-remote.service
Настройки сервера завершены. На данном этапе server.domain готов к приему сообщений от client.domain.
Перейдем к настройке клиента, для того чтобы он смог передавать информацию на сервер.
Приступим к настройке клиента
На клиенте используется компонент systemd-journal-upload, который отвечает за передачу сообщений на сервер.
Для полноценного функционирования компонента systemd-journal-upload, необходимо создать системного пользователя с именем system:
$ sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload
Разберем используемую команду:
--system: создаем пользователя с идентификатором UID ниже 1000.--home /run/systemd: указываем домашний каталог для системного пользователя/run/systemd.--no-create-home: данный параметр позволяет отключить создание домашних каталогов для нашего системного пользователя.--disabled-login: отключение входа в нашей системе для системного пользователя (доступ по SSH).--group: создание группыsystem.
Необходимо установить права на файлы сертификатов Let’s Encrypt:
$ sudo chmod 0755 /etc/letsencrypt/{live,archive}
– эти права дают возможность на чтение и выполнение пользователю, а владельцу право на редактирование.
$ sudo chmod 0640 /etc/letsencrypt/live/client.domain/privkey.pem
– эти права дают возможность владельцу право на чтение и запись, группе только чтение.
Назначим группе systemd-journal-upload право на владение закрытым ключом:
$ sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.domain/privkey.pem
Редактирует файл конфигурации /etc/systemd/journal-upload.conf:
$ sudo nano /etc/systemd/journal-upload.conf
Приводим к следующему виду:
Перезапускаем сервис systemd-journal-upload, для того, чтобы применить измененную конфигурацию:
$ sudo systemctl restart systemd-journal-upload.service
Настройки клиента завершены. Теперь он может передавать сообщения лог-файлов на сервер-централизации. Осталось провести проверку на работоспособность произведенных настроек.
Тестирование системы централизованного логирования
Централизованный сервер логирования хранит информацию хост-клиентов в каталоге /var/log/journal/remote/. После перезапуска клиента client.domain он уже передал сообщения логов. Имя файла в каталоге должно совпадать с используемым именем хоста, зарегистрированным в TLS-сертификате.
Проверим наличие лог-файла на сервер. Для этого введем команду ls -la:
$ sudo ls -la /var/log/journal/remote/
Результат выполнения команды:
Для проверки регистрации событий на сервере, используем утилиту logger. Если все работает правильно, то systemd-journal-upload отправит сообщение на сервер-централизации.
Введем следующую команду на client.domain:
$ sudo logger -p syslog.debug “test message from client.domain”
В этой команде параметр -p syslog.debug устанавливает субъекта (syslog) и уровень важности сообщения (debug). Указывая syslog.debug, мы отправим тестовое сообщение.
Этой командой мы запишем сообщение “test message from client.domain” в лог-файл хост-клиента. В свою очередь сервис systemd-journal-upload отправит ее на сервер централизации.
После выполнения команды, проверим правильность записи лог-файла клиента на сервере. Прочитать лог-файл можно только компонентом journalctl с ключом -file:
$ sudo journalctl --file=/var/log/journal/remote/remote-CN=client.domain.journal
Мы получим следующее сообщение:
Сервер исправно получил данные от клиента.
Сделаем вывод. Все настройки, которые мы применили в организации нашей системы централизованного хранения и передачи лог-файлов, исправно работают и могут быть применимы в проектах. Наш сервер централизации прекрасно сопряжен с хост-клиентом и может благополучно принимать и хранить лог-журналы.
