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

Вступ

• Переваги централізованого зберігання журналів 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