Накратко: С unattended-upgrades под Debian и Ubuntu и с dnf-automatic в семейството RHEL Linux сървърите инсталират самостоятелно актуализации за сигурност. За да действа една актуализация, засегнатите услуги като PHP-FPM трябва след това да се рестартират; проверете това с needrestart или с началните времена на процесите. Външни източници като sury.org трябва да се разрешат изрично, контейнерите и смяната на основна версия автоматиката не покрива.
От пача до сървъра: автоматиката спестява време
Когато php.net публикува на 21 октомври 2026 г. в 16 ч. германско време пачовете срещу PHP2Shell, за администраторите започна състезание. Според съобщения дистрибуциите доставиха своите backport корекции понякога още същия ден. Сървърите с автоматични актуализации за сигурност можеха да инсталират новите пакети при следващото планирано изпълнение, без някой да се намесва.
Това е добрата новина. По-малко добрата: инсталирано не значи действащо. Услуга PHP-FPM, която работи от седмици, продължава да работи със стария код в паметта, докато не бъде рестартирана. А пакетите от външни източници, контейнерите или хостинг панелите със собствено управление на PHP често остават недокоснати от автоматиката.
Тази статия показва как да настроите автоматични актуализации за сигурност и да ги допълните така, че в критичен момент наистина да защитават.
unattended-upgrades под Debian и Ubuntu
Под Ubuntu пакетът unattended-upgrades е инсталиран по подразбиране и инсталира актуализации за сигурност. Под Debian го инсталирате допълнително при нужда. Управлява се чрез два файла в /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Файлът 20auto-upgrades определя дали и колко често се обновяват списъците с пакети и се инсталират актуализации. Стойността е броят на дните, "1" означава ежедневно:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
В 50unattended-upgrades е записано от кои източници могат да идват актуализации, дали след това се рестартира и кой получава съобщение. По подразбиране са разрешени само официалните източници за сигурност на дистрибуцията. Според документацията на Ubuntu не е достатъчно да включите друго хранилище: то трябва допълнително да е в този списък, иначе автоматиката го игнорира. Това засяга например хранилището на трета страна sury.org, което според съобщения е предоставяло PHP версии за всички клонове от 5.6 до 8.5. Контекст има в статията Хранилището sury.org.
Дали всичко е наред, показва пробно изпълнение, което нищо не променя:
sudo unattended-upgrade -v --dry-run
# Протоколи на истинските изпълнения
ls -l /var/log/unattended-upgrades/
dnf-automatic на RHEL, AlmaLinux и Rocky Linux
В семейството RHEL dnf-automatic поема същата задача. Конфигурацията е в /etc/dnf/automatic.conf. Според документацията upgrade_type = security проверява само актуализации със съобщение за сигурност, а apply_updates по подразбиране е изключено.
# /etc/dnf/automatic.conf (откъс)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Освен dnf-automatic.timer, който следва конфигурационния файл, има таймери, които само съобщават, само изтеглят или винаги инсталират. За начало таймерът с конфигурационен файл е най-проследим.
Подценяваната част: рестартиране на услугите
Управлението на пакети заменя файлове на диска. Работещите процеси запазват стария код в паметта. При PHP това значи: докато PHP-FPM или Apache с mod_php не са рестартирани, уязвимостта остава отворена.
| Инструмент | Система | Какво прави |
|---|---|---|
| needrestart | Debian, Ubuntu | разпознава услуги с остарели файлове; под Ubuntu от 24.04 ги рестартира по подразбиране автоматично |
dnf needs-restarting -s |
семейство RHEL | изброява услуги, които трябва да се рестартират |
Automatic-Reboot |
unattended-upgrades | рестартира сървъра, когато актуализация го изисква; по подразбиране изключено |
reboot |
dnf-automatic | never, when-changed или when-needed |
Според документацията на Ubuntu услугите, изключени от needrestart, продължават да работят със стари файлове до ръчното рестартиране. Затова след всяка актуализация на PHP проверявайте началното време на процесите, както е описано в Рестартиране на PHP-FPM и на всички worker процеси.
При backport корекции показваният номер на версията на PHP често остава същият. Пача доказвате през changelog на пакета с номерата на CVE, например с apt-get changelog или rpm -q --changelog. Как става това в детайли, показва Debian и Ubuntu: пачнат ли е моят пакет на PHP?.
Какво автоматиката не покрива
Автоматичните актуализации са градивен елемент, не пълно управление на пачовете. Някои области изискват собствени процеси:
- Контейнери: PHP в образи на Docker не се актуализира чрез актуализации на хоста. Изградете образите наново, създайте контейнерите наново.
- Хостинг панели: Plesk, cPanel и подобни панели управляват PHP частично чрез собствени пакети и механизми.
- Основни версии: преминаването например от PHP 8.2, което достига края на поддръжката на 31.12.2026 г., към по-нова версия не става автоматично.
- Приложения: CMS, добавки и зависимости на Composer имат собствени пътища за актуализация.
- Контрол: някой трябва да чете протоколите и съобщенията за грешки на автоматиката. Тихо проваляща се автоматика е по-лоша от никаква, защото създава привидна сигурност.
Как тези части се сливат в един процес, описва Управление на пачовете като процес, а не като гасене на пожари.
Извод: автоматика да, сляпо доверие не
Автоматичните актуализации за сигурност принадлежат на всеки Linux сървър, достъпен от интернет. PHP2Shell показа колко оскъдно може да стане времето: според съобщения в медиите първи опит за атака е наблюдаван още на 17 октомври, четири дни преди пачовете. Който след това още чака ръчен прозорец за поддръжка, губи ценно време.
Автоматиката обаче Ви освобождава само от инсталирането. Рестартирането на услугите, доказването на състоянието на пачовете, контейнерите, панелите и навременният преход към поддържани версии остават задачи, за които някой трябва да отговаря. Определете тази отговорност писмено и проверявайте избирателно дали протоколите на автоматиката действително се четат. Едва комбинацията от автоматика и контрол прави актуализациите надеждни.
Как помага PHP SOS конкретно?
- Настройка: конфигурираме unattended-upgrades или dnf-automatic според Вашите сървъри, включително разрешените външни източници.
- Осигуряване на рестартиранията: настройваме needrestart или съответни проверки и след актуализации на PHP проверяваме началните времена на процесите.
- Затваряне на пропуските: контейнери, панели и смяна на основни версии включваме във фиксиран процес на поддръжка.
- Контрол: в договора за поддръжка на сигурността проверяваме протоколите на автоматиката и съобщаваме за необичайното.
Често задавани въпроси
Не са ли автоматичните актуализации твърде рискови на продукционни сървъри?
Ограничени до актуализациите за сигурност на дистрибуцията, рискът обикновено е по-малък от този на отворена уязвимост. Тези актуализации не трябва да носят нови функции, а да отстраняват грешки. За критични системи принадлежат резервни копия, мониторинг и тестова система.
Рестартира ли unattended-upgrades PHP-FPM след актуализация?
Не непременно сам. Под Ubuntu от версия 24.04 инструментът needrestart по подразбиране рестартира засегнатите услуги автоматично, но изключените услуги продължават да работят със стари файлове. След всяка актуализация на PHP проверявайте началното време на всички PHP процеси.
Актуализират ли се автоматично пакетите от sury.org или други външни източници?
Само ако изрично разрешите източника. Според документацията на Ubuntu не е достатъчно да добавите хранилище; то трябва допълнително да е в списъка с разрешени произходи на unattended-upgrades.
Вдига ли автоматиката PHP 8.2 до 8.3?
Не. Автоматичните актуализации за сигурност остават в рамките на инсталираните версии на пакетите. Смяната на основната версия на PHP, например преди края на поддръжката на PHP 8.2 на 31.12.2026 г., остава планиран проект с тестове.
Какво е положението с контейнерите на Docker?
Актуализациите на хоста не актуализират версията на PHP в контейнерите. Образите на контейнерите трябва да се изградят наново или да се изтеглят наново, а контейнерите да се създадат наново.