Статья также доступна на украинском (перейти к просмотру).

Оглавление

• Преимущества централизованного хранения журналов Linux-систем
• Исходные данные и наши шаги по созданию кластера
• Обновление программных пакетов
• Установка компонентов подсистемы systemd
• Настройки брандмауэров
• Установка ACME-клиента
• Регистрация сертификатов
• Настройка серверного узла
• Настройки клиентского узла
• Проверка работоспособности узлов кластера

Значительность журналирования на Linux-серверах трудно переоценить, о чем мы уже говорили в статье, посвященной журналам аутентификации в Ubuntu. Однако ситуация усложняется в случае необходимости управления не одним сервером, а целым кластером. Это обусловлено локальным хранением журналов на каждом узлов кластера, что не позволяет иметь к ним полный доступ для любого постороннего процесса или Администратора. Решением может стать использование отдельного сервера для централизованного хранения журналов узлов. Попробуем изучить этот вопрос и сделать кластер, работающий на указанных критериях. Кстати о другом варианте хранения логов на удаленном сервере мы уже писали в статье “Управление логами с помощью Logrotate”

Преимущества централизованного хранения журналов Linux-систем

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

• Возможность беспрепятственного доступа для Администраторов к журналам любого узла кластера;
• Экономия места на диске для каждого из узлов, количество которых почти не ограничено;
• Возможность длительного хранения журналов за счет выделения отдельных накопителей на центральном сервере;
• Расширенные возможности использования информации из журналов – проведение анализа на уровне одного или нескольких журналов, неограниченные возможности по сопоставлению имеющихся данных, более мощные аппаратные возможности по обработке информации и т.д.

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

Исходные данные и наши шаги по созданию кластера

Наш кластер будет состоять из двух машин – сервера и клиента, на каждом из которых будет установлена ОС Ubuntu 22.04. В качестве серверов будем использовать облачные серверы с Ubuntu FREEhost.UA.

Исходные данные:

Домен сервера: cf1280475.test-domain123.kiev.ua
Пользователь сервера: super_user

Домен клиента: cf1317758.test-domain123.kiev.ua
Пользователь клиенту: admin

Перечень наших шагов будет следующим:

• Обновление программных пакетов на обеих машинах;
• Установка компонентов подсистемы systemd, обеспечивающих передачу и прием записей журналов между сервером и клиентом;
• Настройка брандмауэров, предусматривающая открытие портов для управляющих процессов;
• Установка ACME-клиента для возможности автоматического управления SSL/TLS сертификатами от Let's Encrypt;
• Регистрация сертификатов для серверного и клиентского узлов;
• Настройка серверного узла;
• Настройка клиентского узла;
• Проверка работоспособности узлов кластера.

Обновление программных пакетов

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

Сервер

Обновим индекс пакетов на сервере:

$ sudo apt update

Обновим пакеты:

$ sudo apt upgrade

Подтверждаем выделение дополнительных 594 Mb дискового пространства, после чего процесс обновления ПО начнется.

Обновление ПО на сервере завершено.

Клиент

Обновим ПО на клиентском узле. Для этого наберем в терминале:

$ sudo apt update

$ sudo apt upgrade

Подтверждаем выделение дополнительных 65,1 Mb на диске для активации процесса обновления пакетов.

Обновление пакетов прошло успешно.

Установка компонентов подсистемы systemd

Для возможности реализации процесса «общения» клиентов с сервером, в частности, пересылка на сервер копий записей системных журналов, необходимо на всех машинах кластера установить соответствующие компоненты подсистемы инициализации служб Systemd.

Сервер

Сначала установим на сервере даэмона для скачивания и приема информации от клиентов. Для этого введем в терминале:

$ sudo apt install systemd-journal-remote

Соглашаемся на выделение дополнительных 599 Kb и активируем процесс инсталляции.

Итак, компонент установлен – «Setting up systemd-journal-remote (249.11-0ubuntu3.11)».

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

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

Здесь параметр --now необходим для немедленного запуска процесса.

Теперь активируем службу, которая обеспечивает прием сообщений от клиентов:

$ sudo systemctl enable systemd-journal-remote.service

Пока эта служба не запущена, поскольку для ее работы необходимо иметь SSL/TLS сертификаты, которые мы получим позже.

Клиент

Сначала установим даэмон systemd-journal-remote. Для этого наберем следующую команду:

$ sudo apt install systemd-journal-remote

Соглашаемся на выделение 599 Kb.

Даемон успешно установлен – «Setting up systemd-journal-remote (249.11-0ubuntu3.11)».

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

$ sudo systemctl enable systemd-journal-upload.service

Настройки брандмауэров

Для возможности приема и передачи сообщений по сети на всех узлах кластера должны быть открыты соответствующие порты. Для их настройки воспользуемся возможностями брандмауэров UFW обоих узлов и откорректируем установленные для них правила.

Сервер

На сервере должны быть открыты порты с номерами 19532 и 80. В частности, порт 80 требуется ACME-клиенту для генерирования SSL/TLS сертификатов. Для этого воспользуемся следующими командами:

$ sudo ufw allow in 19532/tcp

$ sudo ufw allow in 80/tcp

Правила для брандмауэра успешно обновлены – «Rules updated».

После этого обновим правила на клиентском узле.

Клиент

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

$ sudo ufw allow in 80/tcp

Правила успешно обновлены!

Порты на обеих машинах настроены и поэтому можно переходить к регистрации SSL/TLS сертификатов для всех узлов кластера.

Установка ACME-клиента

SSL/TLS сертификаты позволяют узлам сети шифровать передаваемые данные и выполнять взаимную аутентификацию. Это становится возможным за счет использования в браузере защищенного https протокола.

Для использования в нашем проекте выбираем бесплатные TLS сертификаты от Let’s Encrypt. Для работы с ними нам понадобится один из ACME-клиентов, в качестве которого применима утилита Certbot. Она поможет нам сначала зарегистрировать сертификаты и в дальнейшем производить их автоматическое продление в случае истечения срока их действия.

Сначала установим Certbot на сервере.

Сервер

Сначала активируем доступ к одному из репозиториев Ubuntu, к которому относится программа Certbot. Для этого введем в терминале:

$ sudo apt install software-properties-common

$ sudo add-apt-repository universe

Здесь universe – репозиторий, который нам необходим.

Теперь обновим индекс пакетов:

$ sudo apt update

После этого можно начинать установку ACME-клиента. Наберем в терминале:

$ sudo apt install certbot

Соглашаемся с выделением дополнительных 4,915 Kb на диске и начинаем процесс установки программы.

Программа успешно установлена – «Setting up certbot (1.21.0-1build1)».

Клиент

Как и на сервере, откроем доступ для apt-менеджера к репозиторию universe:

$ sudo apt install software-properties-common

$ sudo add-apt-repository universe

Обновим индекс:

$ sudo apt update

Установим программу certbot:

$ sudo apt install certbot

Выделяем дополнительное место на диске и продолжаем процесс.

Программа установлена – «Setting up certbot (1.21.0-1build1)».

Регистрация сертификатов

Теперь пришел черед регистрации сертификатов на обоих узлах. Начнем с сервера.

Сервер

Запустим ACME-клиент с соответствующими параметрами. Для этого наберем в терминале:

$ sudo certbot certonly --standalone --agree-tos --email alexandr7500@cf1280475.test-domain123.kiev.ua -d cf1280475.test-domain123.kiev.ua

Здесь параметр --agree-tos указывает на наше согласие на принятие условий обслуживания в Let’s Encrypt; параметр –standalone указывает на необходимость использования устроенного веб-сервера Certbot для проверки запроса на сертификат; указанный email-адрес необходим для получения от Центра сертификации сообщений об истечении срока действия сертификата; cf1280475.test-domain123.kiev.ua – имя хоста, для которого будет регистрироваться сертификат.

Подтверждаем свое согласие на получение уведомлений от владельцев сервиса Certbot, после чего активируется процесс регистрации сертификата.

Выход команды:

• Сертификат успешно получен (Successfully received certificate) и сохранен по адресу: /etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/fullchain.pem;
• Ключ сохранен по адресу: /etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/privkey.pem;
• Срок действия сертификата истекает 28 марта 2024 года;
• Указанные файлы будут обновляться в случае продления срока действия сертификата;
• Certbot настроил запланированное задание на автоматическое продление срока действия сертификата в фоновом режиме.

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

Служба Journald будет использовать его для совместной проверки сертификатов сервера и клиента при их взаимодействии между собой.

Введем в терминале следующую команду для создания объединенного файла:

$curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

Здесь letsencrypt-combined-certs.pem – объединенный файл сертификатов.

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

$ sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/

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

Клиент

Запустим программу Certbot для регистрации сертификата:

$ sudo certbot certonly --standalone --agree-tos --email alexandr7500@cf1317758.test-domain123.kiev.ua -d cf1317758.test-domain123.kiev.ua

Сертификат успешно получен – «Successfully received certificate».

Все остальные сообщения программы аналогичны сообщениям на сервере, за исключением названия хоста для клиента.

Создадим объединенный файл сертификатов:

$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/cf1317758.test-domain123.kiev.ua/

Итак, процесс регистрации сертификатов завершен.

Теперь наша задача настроить сервер таким образом, чтобы он отслеживал и сохранял сообщения журналов, передаваемых клиентскими узлами.

Настройка серверного узла

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

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

Внесем следующие изменения в раздел [Remote] файла:

[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/letsencrypt-combined-certs.pem

Указанные здесь параметры имеют следующие значения:

SplitMode – указание на способ хранения журналов разных клиентов (объединять или разделять по хостам);

Seal – дает возможность активировать подпись данных в журнале (повышает уровень защиты);

TrustedCertificateFile – указывает путь к месту размещения файла объединенного сертификата.

ServerKeyFile – указывает путь к файлу ключа;

ServerCertificateFile – указывает путь к файлу сертификата.

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

Сохраним внесенные изменения и выйдем из редактора.

Изменим разрешения для доступа к каталогам с ключом и сертификатом. Для этого наберем в терминале:

$ sudo chmod 0755 /etc/letsencrypt/{live,archive}

$ sudo chmod 0640 /etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/privkey.pem

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

$ sudo chgrp systemd-journal-remote /etc/letsencrypt/live/cf1280475.test-domain123.kiev.ua/privkey.pem

Запустим службу systemd-journal-remote с помощью следующей команды:

$ sudo systemctl start systemd-journal-remote.service

В результате сервер для хранения журналов запущен и готов к приему сообщений от клиентских узлов.

После этого нам остается только настроить соответствующим образом клиентский узел для возможности генерирования и передачи сообщений журнала на сервер.

Настройка клиентского узла

Настройка узла по сути сводится к настройке службы systemd-journal-upload, отвечающей за отправку сообщений на сервер.

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

Для этого введем следующую команду:

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

Установим разрешения для владельца файлов сертификатов:

$ sudo chmod 0755 /etc/letsencrypt/{live,archive}

$ sudo chmod 0640 /etc/letsencrypt/live/cf1317758.test-domain123.kiev.ua/privkey.pem

Изменим группу владельца закрытого ключа на системную группу systemd-journal-upload:

$ sudo chgrp systemd-journal-upload /etc/letsencrypt/live/cf1317758.test-domain123.kiev.ua/privkey.pem

После этого внесем изменения в настройки systemd-journal-upload в файле конфигурации этой службы:

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

Внесем следующие изменения в раздел [Upload]:

[Upload]
URL=https://cf1280475.test-domain123.kiev.ua:19532
ServerKeyFile=/etc/letsencrypt/live/cf1317758.test-domain123.kiev.ua/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/cf1317758.test-domain123.kiev.ua/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/cf1317758.test-domain123.kiev.ua/letsencrypt-combined-certs.pem

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

Перезагрузим службу, чтобы внесенные изменения вступили в силу:

$ sudo systemctl restart systemd-journal-upload.service

Итак, мы настроили наш клиентский узел – теперь он готов к отправке сообщений журнала на сервер.

Проверка работоспособности узлов кластера

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

Место, где сервер хранит журналы клиентов, является каталог/var/log/journal/remote/.

Сразу же после перезапуска нами служб клиента он начал отправлять сообщения на сервер и поэтому здесь уже должен быть файл его журнала. Его имя будет соответствовать имени хоста, для которого был выдан TLS-сертификат. Проверим это, просмотрев содержимое указанного каталога на сервере. Для этого наберем в терминале:

$ sudo ls -la /var/log/journal/remote/

Ниже приведена выборка записей:

total 712748
 
drwxr-xr-x      2      systemd-journal-remote    systemd-journal-remote    4096 Jan  1 13:11  .
drwxr-sr-x+   4      root            	                   systemd-journal      	       4096 Dec 29 17:37  ..
 
-rw-r-----       1     systemd-journal-remote    systemd-journal-remote    75497472   Jan  1 13:10 'remote-CN=cf1317758.test-domain123.kiev.ua@6c8fbad904c84961a39dae6aa6c4b873-0000000000000001-0005dece9bd324e5.journal'
 
-rw-r-----     1	 systemd-journal-remote	 systemd-journal-remote    75497472   Jan  1 13:11 'remote-CN=cf1317758.test-domain123.kiev.ua@6c8fbad904c84961a39dae6aa6c4b873-0000000000011aac-0005f3465c609388.journal'

Следовательно, сообщения от клиентского узла с именем cf1317758.test-domain123.kiev.ua были приняты сервером и сохранены в каталоге журналов. Это означает, что наш кластер с централизованным журналом создан и готов к работе. Конечно, существует возможность его дальнейшего масштабирования за счет добавления новых узлов аналогично тому, как это было сделано нами с клиентом cf1317758.

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

Подписывайтесь на наш телеграмм-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.

Смотрите наш канал Youtube на https://www.youtube.com/freehostua.

>

Мы в чем ошиблись, или что-то пропустили?

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

Дата: 08.01.2024 Автор: Александр Ровник #devops#linux#security#ubuntu

Голосование 1 2 3 4 5