Налаштування автоматичного оновлення Ubuntu Server без перезавантаження

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

Навіть мінімальна інсталяція Ubuntu складається з десятків окремих компонентів, таких як безпосередньо ядро системи, SSH, веб-сервер, бібліотеки, інтерпретатори мов, інструменти адміністрування тощо. Усе це регулярно оновлюється.

При цьому далеко не кожне оновлення системи призводить до простою, оскільки Ubuntu Server вміє самостійно встановлювати виправлення безпеки, а частину оновлень ядра можна застосовувати взагалі без перезавантаження завдяки технології Livepatch, що дуже стане в нагоді для серверів, чутливих до простоїв.

Такий підхід особливо зручний, якщо на сервері працюють сайти, CRM, API, поштові служби, бази даних або внутрішні сервіси компанії, які, по можливості, не повинні перезавантажуватися. Знову ж таки, адміністратору доводиться виконувати менше рутинних операцій, а вікно, протягом якого систему можна атакувати через вже відому вразливість, стає помітно коротшим.

Після оприлюднення нової уразливості часу на захист сервера зазвичай залишається небагато, оскільки сканування Інтернету починається майже відразу, а автоматичні боти швидко знаходять сервери, власники яких вирішили відкласти оновлення на потім з тих чи інших причин. У підсумку, чим довше відкладається встановлення виправлень, тим вища ймовірність, що уразливість встигнуть використати.

 

 

 

 

Автоматичне встановлення оновлень

Проблема автоматичного встановлення оновлень в Ubuntu давно вирішена за допомогою стандартних засобів. За це відповідає пакет unattended-upgrades, який самостійно перевіряє наявність оновлень, завантажує їх і встановлює без участі адміністратора.

Встановлення цього пакета займає кілька хвилин і виконується за допомогою таких команд:

sudo apt update

sudo apt install unattended-upgrades

 

Після цього варто запустити майстер налаштування:

sudo dpkg-reconfigure unattended-upgrades

Під час налаштування система запитає, чи потрібно автоматично встановлювати оновлення безпеки. У більшості випадків доцільно вибрати Yes.

 

 

 

 

Де знаходяться налаштування

Робота утиліти unattended-upgrades визначається двома файлами.

Перший файл - це /etc/apt/apt.conf.d/50unattended-upgrades. Тут вказується, які оновлення дозволено встановлювати автоматично. У цьому ж файлі можна змінити додаткові параметри, такі як:

• список використовуваних репозиторіїв;
• автоматичне видалення залежностей, які більше не потрібні;
• очищення кешу пакетів;
• надсилання повідомлень електронною поштою;
• автоматичне перезавантаження після встановлення оновлень.

Конфігурація детально прокоментована, тому розібратися в налаштуваннях буде зовсім нескладно.

 

Другий файл - /etc/apt/apt.conf.d/20auto-upgrades. Він відповідає за періодичність запуску. Найпоширеніший приклад конфігурації може виглядати так:

APT::Periodic::Update-Package-Lists «1»;

APT::Periodic::Unattended-Upgrade «1»;

 

Ця конфігурація означає наступне:

• Update-Package-Lists - щодня оновлювати список пакетів;
• Unattended-Upgrade - щодня встановлювати дозволені оновлення.

 

За бажанням розклад можна змінити. Наприклад, запускати автоматичне оновлення раз на кілька днів замість щоденного розкладу.

 

 

 

 

Як перевірити, чи працює механізм

Після налаштування автоматичного оновлення не зайвим буде переконатися, що все дійсно функціонує так, як ми задумали. Для цього спочатку можна перевірити стан основної служби за допомогою команди:

systemctl status unattended-upgrades

 

Потім варто перевірити журнал оновлень:

cat /var/log/unattended-upgrades/unattended-upgrades.log

 

Або скористатися журналом systemd:

journalctl -u unattended-upgrades

 

Якщо механізм працює нормально, то в логах будуть видні завантажені пакети, встановлені оновлення та можливі помилки під час їх встановлення.

 

 

 

 

Коли потрібне перезавантаження, а коли ні

Існує поширена думка, що після будь-якого оновлення сервера Linux обов’язково потрібно перезавантажувати систему. Але це зовсім не так, адже більшість пакетів оновлюється без зупинки операційної системи. Після встановлення нової версії зазвичай достатньо перезапустити лише той сервіс, який використовує оновлені файли.

Наприклад, після оновлення веб-сервера Nginx можна просто виконати команду:

sudo systemctl reload nginx

або після оновлення PostgreSQL виконати:

sudo systemctl restart postgresql

 

Для користувачів вашого сайту чи додатка такі дії найчастіше проходять непомітно.

 

Зворотна ситуація виникає під час оновлення безпосередньо ядра системи Linux. Нова версія встановлюється на диск, але сервер продовжує працювати зі старим ядром, яке вже знаходиться в оперативній пам’яті. Тому доки система не буде перезавантажена - зміни не набудуть чинності.

Саме тому після деяких оновлень Ubuntu виводить повідомлення:

System restart required

 

Перезавантаження може знадобитися й після оновлення деяких системних компонентів, які неможливо замінити «на льоту». Зазвичай йдеться про такі компоненти, як:

• systemd;
• glibc;
• драйвери обладнання;
• мікрокод процесора;
• окремі компоненти віртуалізації.

 

У всіх інших випадках достатньо перезапустити лише потрібні служби, не зачіпаючи роботу всього сервера. Це дозволяє встановлювати більшість оновлень без помітного простою.

 

 

 

 

Canonical Livepatch

Щоб скоротити кількість перезавантажень, Canonical розробила технологію Livepatch. Вона дозволяє застосовувати багато критичних виправлень безпеки безпосередньо до ядра Linux, що працює, без зупинки системи та без перезапуску сервера.

Як ми дізналися вище, після оновлення ядра нова версія починає використовуватися лише після перезавантаження сервера. Але Livepatch забезпечує, щоб виправлення для підтримуваних вразливостей завантажувалися в пам’ять і застосовувалися до ядра, що вже працює. Завдяки цьому сервер продовжує обслуговувати користувачів, а позапланове вікно обслуговування не потрібне.

Для використання цієї технології знадобиться обліковий запис Ubuntu One. Після реєстрації достатньо встановити на свій сервер клієнт Livepatch, прив’язати сервер до свого облікового запису та активувати сервіс. Подальша інсталяція підтримуваних виправлень відбувається автоматично у фоновому режимі.

Найбільшу користь Livepatch приносить там, де навіть короткий простой є небажаним. Наприклад:

• VPS із високими вимогами до доступності;
• виробничі веб-сервери;
• сервери баз даних;
• корпоративні додатки;
• хмарна інфраструктура.

 

При цьому слід розуміти, що можливості Livepatch не безмежні. Ця технологія поширюється лише на певні виправлення безпеки ядра і не замінює повноцінних оновлень. Тому якщо виходить нова версія ядра, змінюються внутрішні механізми його роботи або встановлюються великі функціональні оновлення, то планове перезавантаження сервера все одно залишається необхідним. Саме тому Livepatch варто розглядати як спосіб скоротити кількість перезавантажень сервера, а не як спосіб відмовитися від них повністю.

 

 

 

 

Як дізнатися, чи потрібне перезавантаження

Після встановлення деяких оновлень Ubuntu автоматично створює спеціальний файл-маркер. Його поява означає, що частина встановлених змін почне працювати лише після перезавантаження системи.

Перевірити наявність такого файлу можна командою:

test -f /var/run/reboot-required && echo «Reboot required»

 

або просто:

ls /var/run/reboot-required

 

Якщо файл існує, то відкладати перезавантаження нескінченно не варто. Сам сервер продовжить працювати, однак оновлене ядро або окремі системні компоненти залишаться неактивними до наступного запуску.

У великих інфраструктурах цей механізм нерідко використовують разом із системами моніторингу та засобами управління конфігурацією, які автоматично відстежують появу файлу reboot-required, повідомляють адміністраторів і допомагають планувати обслуговування серверів без постійної ручної перевірки.

 

 

 

 

Як визначити процеси зі старими бібліотеками

Після оновлення бібліотек деякі служби продовжують використовувати вже завантажені версії файлів. І доки процес не буде перезапущено, зміни не набудуть чинності.

Перевірити це допомагає утиліта needrestart.

Для встановлення цієї утиліти виконайте команду:

sudo apt install needrestart

 

Запускаємо утиліту командою:

sudo needrestart

 

Після аналізу програма покаже:

• служби, які бажано перезапустити;
• необхідність повного перезавантаження;
• процеси, що продовжують використовувати старі версії бібліотек.

 

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

 

 

 

 

Практичні рекомендації

Автоматична установка оновлень позбавляє адміністратора великого обсягу рутинної роботи, але повністю залишати сервер без контролю все ж не варто. Навіть надійні механізми на кшталт unattended-upgradesкорисно час від часу перевіряти, особливо якщо система обслуговує робочі проєкти.

Перед увімкненням автоматичних оновлень бажано:

• налаштувати резервне копіювання;
• перевірити оновлення на тестовому сервері, якщо йдеться про критичну інфраструктуру;
• періодично переглядати журнали роботи unattended-upgrades;
• відстежувати необхідність перезавантаження;
• контролювати стан сервісів після встановлення оновлень;
• час від часу виконувати повноцінне оновлення системи вручну.

 

Гарною практикою вважається й використання моніторингу. Якщо після встановлення оновлень якийсь сервіс перестане відповідати або знадобиться перезавантаження, то адміністратор дізнається про це одразу, а не через кілька годин чи днів.

Для VPS та виділених серверів із високим навантаженням доцільно заздалегідь планувати вікна обслуговування. Більшість оновлень встановлюються автоматично й без простою, проте оновлення ядра, перевірка працездатності сервісів або інші адміністративні завдання все одно зручніше виконувати за заздалегідь узгодженим графіком.

 

 

 

 

FAQ або Поширені запитання

Чи можна повністю відмовитися від ручних оновлень?

Для більшості невеликих серверів це цілком реально. Але якщо інфраструктура є критичною для бізнесу, то краще періодично перевіряти її вручну, контролювати стан сервісів і переглядати журнали після встановлення оновлень.

 

Наскільки безпечні автоматичні оновлення?

Оновлення безпеки проходять тестування перед публікацією, тому ймовірність виникнення проблем невелика. Проте резервні копії мають залишатися обов’язковою частиною будь-якої серверної інфраструктури.

 

Чи варто автоматично оновлювати абсолютно всі пакети?

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

 

Чи можна тимчасово вимкнути автоматичні оновлення?

Так. Іноді це роблять перед значними змінами в інфраструктурі, міграцією сервісів або оновленням додатків. Після завершення робіт автоматичне оновлення краще знову увімкнути, щоб сервер не залишався без актуальних виправлень безпеки.

 

Чи замінює Livepatch звичайне оновлення ядра?

Ні. Livepatch встановлює лише частину критичних виправлень безпеки для підтримуваних версій ядра. Але повноцінні оновлення ядра та планові перезавантаження все одно залишаються необхідними.

 

Як часто варто перевіряти журнали автоматичних оновлень?

Якщо сервер працює стабільно, зазвичай достатньо переглядати журнали раз на кілька тижнів або після отримання повідомлень системи моніторингу. На серверах із високим навантаженням або критичними сервісами контроль журналів нерідко включають до регулярних регламентних перевірок.

 

 

 

 

Висновки

Автоматичне оновлення Ubuntu Server дозволяє підтримувати систему в актуальному стані без постійної участі адміністратора. Пакет unattended-upgrades самостійно встановлює дозволені оновлення, needrestart допомагає визначити, які служби потребують перезапуску, а Canonical Livepatch у деяких випадках дозволяє обійтися без перезавантаження навіть після виправлення вразливостей ядра.

Але повністю відмовитися від контролю все ж не вдасться. Створення резервних копій, моніторинг, перевірка журналів, контроль необхідності перезавантаження та планові вікна обслуговування залишаються невід’ємною частиною експлуатації будь-якого сервера.

У результаті адміністратор витрачає менше часу на рутинні завдання, а сервер швидше отримує виправлення безпеки. Для VPS, виділених серверів та будь-якої сучасної інфраструктури такий підхід вже давно став стандартною практикою, тому й вам варто розглянути можливість впровадження цього механізму у своїй інфраструктурі, з урахуванням, звісно, усіх практичних рекомендацій, які ми вам надали.