Krótko: Za pomocą unattended-upgrades w Debianie i Ubuntu oraz dnf-automatic w rodzinie RHEL serwery Linux samodzielnie wgrywają aktualizacje zabezpieczeń. Aby aktualizacja zadziałała, dotknięte usługi, takie jak PHP-FPM, muszą się potem zrestartować; proszę to sprawdzić za pomocą needrestart lub czasów uruchomienia procesów. Źródła zewnętrzne, takie jak sury.org, trzeba wyraźnie udostępnić, a kontenerów i zmian wersji głównych automatyka nie obejmuje.
Od poprawki do serwera: automatyka oszczędza czas
Gdy php.net 21 października 2026 o godzinie 16:00 czasu niemieckiego opublikował poprawki przeciw PHP2Shell, dla administratorów zaczął się wyścig. Według doniesień dystrybucje dostarczały swoje backporty częściowo jeszcze tego samego dnia. Serwery z automatycznymi aktualizacjami zabezpieczeń mogły zainstalować nowe pakiety przy następnym zaplanowanym przebiegu, bez konieczności czyjejkolwiek interwencji.
To dobra wiadomość. Mniej dobra: zainstalowane nie znaczy skuteczne. Usługa PHP-FPM, która działa od tygodni, pracuje dalej ze starym kodem w pamięci, aż zostanie zrestartowana. A pakiety ze źródeł zewnętrznych, kontenery lub panele hostingu z własnym zarządzaniem PHP często pozostają przez automatykę nietknięte.
Ten artykuł pokazuje, jak skonfigurować automatyczne aktualizacje zabezpieczeń i uzupełnić je tak, aby w poważnej sytuacji naprawdę chroniły.
unattended-upgrades w Debianie i Ubuntu
W Ubuntu pakiet unattended-upgrades jest domyślnie zainstalowany i wgrywa aktualizacje zabezpieczeń. W Debianie instaluje się go w razie potrzeby. Sterowany jest przez dwa pliki w /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Plik 20auto-upgrades określa, czy i jak często odświeżane są listy pakietów i wgrywane aktualizacje. Wartość to liczba dni, "1" oznacza codziennie:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
W 50unattended-upgrades zapisano, z jakich źródeł mogą pochodzić aktualizacje, czy po nich następuje restart i kto otrzymuje wiadomość. Domyślnie udostępnione są tylko oficjalne źródła zabezpieczeń dystrybucji. Według dokumentacji Ubuntu nie wystarczy dołączyć kolejnego repozytorium: musi ono dodatkowo znajdować się na tej liście, w przeciwnym razie automatyka je ignoruje. Dotyczy to na przykład repozytorium zewnętrznego dostawcy sury.org, które według doniesień udostępniało kompilacje PHP dla wszystkich gałęzi od 5.6 do 8.5. Tło znajduje się w artykule Repozytorium sury.org.
To, czy wszystko się zgadza, pokazuje próbny przebieg, który niczego nie zmienia:
sudo unattended-upgrade -v --dry-run
# Dzienniki prawdziwych przebiegów
ls -l /var/log/unattended-upgrades/
dnf-automatic w RHEL, AlmaLinux i Rocky Linux
W rodzinie RHEL to samo zadanie przejmuje dnf-automatic. Konfiguracja leży w /etc/dnf/automatic.conf. Według dokumentacji upgrade_type = security sprawdza tylko aktualizacje z informacją o bezpieczeństwie, a apply_updates jest domyślnie wyłączone.
# /etc/dnf/automatic.conf (fragment)
[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*'
Obok dnf-automatic.timer, który podąża za plikiem konfiguracyjnym, istnieją timery, które tylko zgłaszają, tylko pobierają lub zawsze instalują. Na początek timer z plikiem konfiguracyjnym jest najłatwiejszy do prześledzenia.
Niedoceniana część: restart usług
Menedżer pakietów zastępuje pliki na dysku. Działające procesy zachowują stary kod w pamięci. W PHP oznacza to: dopóki PHP-FPM lub Apache z mod_php nie zostaną zrestartowane, luka pozostaje otwarta.
| Narzędzie | System | Co robi |
|---|---|---|
| needrestart | Debian, Ubuntu | rozpoznaje usługi z nieaktualnymi plikami; w Ubuntu od 24.04 domyślnie restartuje je automatycznie |
dnf needs-restarting -s |
rodzina RHEL | wypisuje usługi, które należy zrestartować |
Automatic-Reboot |
unattended-upgrades | restartuje serwer, gdy wymaga tego aktualizacja; domyślnie wyłączone |
reboot |
dnf-automatic | never, when-changed lub when-needed |
Według dokumentacji Ubuntu usługi wyłączone z needrestart działają do ręcznego restartu ze starymi plikami. Dlatego po każdej aktualizacji PHP proszę sprawdzić czas uruchomienia procesów, jak opisano w artykule Restart PHP-FPM i wszystkich procesów roboczych.
Przy backportach wyświetlany numer wersji PHP często pozostaje ten sam. Poprawkę dowodzi się przez changelog pakietu z numerami CVE, na przykład za pomocą apt-get changelog lub rpm -q --changelog. Jak to zrobić szczegółowo, pokazuje artykuł Debian i Ubuntu: czy mój pakiet PHP jest załatany?.
Czego automatyka nie obejmuje
Automatyczne aktualizacje są jednym elementem, a nie pełnym zarządzaniem poprawkami. Niektóre obszary wymagają własnych procedur:
- Kontenery: PHP w obrazach Docker nie jest aktualizowane przez aktualizacje hosta. Obrazy zbudować od nowa, kontenery utworzyć ponownie.
- Panele hostingu: Plesk, cPanel i podobne panele zarządzają PHP częściowo przez własne pakiety i mechanizmy.
- Wersje główne: przejście na przykład z PHP 8.2, które 31.12.2026 osiąga koniec wsparcia, na nowszą wersję nie następuje automatycznie.
- Aplikacje: CMS, wtyczki i zależności Composera mają własne ścieżki aktualizacji.
- Kontrola: ktoś musi czytać dzienniki i komunikaty błędów automatyki. Po cichu zawodzący przebieg jest gorszy niż żaden, bo stwarza pozory bezpieczeństwa.
Jak te elementy zrastają się w proces, opisuje artykuł Zarządzanie poprawkami jako proces zamiast gaszenia pożarów.
Wniosek: automatyka tak, ślepe zaufanie nie
Automatyczne aktualizacje zabezpieczeń należą na każdy serwer Linux dostępny z internetu. PHP2Shell pokazało, jak mało czasu może być: według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17 października, cztery dni przed poprawkami. Kto po tym nadal czeka na ręczne okno serwisowe, traci cenny czas.
Automatyka zdejmuje z Państwa jednak tylko wgrywanie. Restart usług, dowód stanu poprawek, kontenery, panele i terminowe przejście na wspierane wersje pozostają zadaniami, za które ktoś musi odpowiadać. Proszę ustalić tę odpowiedzialność na piśmie i wyrywkowo sprawdzać, czy dzienniki automatyki faktycznie są czytane. Dopiero połączenie automatyki i kontroli czyni aktualizacje wiarygodnymi.
Jak konkretnie pomaga PHP SOS?
- Konfiguracja: konfigurujemy unattended-upgrades lub dnf-automatic odpowiednio do Państwa serwerów, łącznie z udostępnionymi źródłami zewnętrznymi.
- Zabezpieczenie restartów: konfigurujemy needrestart lub odpowiednie kontrole i po aktualizacjach PHP sprawdzamy czasy uruchomienia procesów.
- Zamykanie luk: kontenery, panele i zmiany wersji głównych włączamy do stałej procedury serwisowej.
- Kontrola: w ramach umowy serwisowej bezpieczeństwa sprawdzamy dzienniki automatyki i zgłaszamy nieprawidłowości.
Częste pytania
Czy automatyczne aktualizacje na serwerach produkcyjnych nie są zbyt ryzykowne?
Ograniczone do aktualizacji zabezpieczeń dystrybucji ryzyko jest zwykle mniejsze niż ryzyko otwartej luki. Takie aktualizacje nie mają dostarczać nowych funkcji, lecz usuwać błędy. Dla systemów krytycznych należą do tego kopie zapasowe, monitoring i system testowy.
Czy unattended-upgrades restartuje PHP-FPM po aktualizacji?
Niekoniecznie samo. W Ubuntu od wersji 24.04 narzędzie needrestart domyślnie automatycznie restartuje dotknięte usługi, ale usługi wyłączone z tego działają dalej ze starymi plikami. Po każdej aktualizacji PHP proszę sprawdzić czas uruchomienia wszystkich procesów PHP.
Czy pakiety z sury.org lub innych źródeł zewnętrznych są aktualizowane automatycznie?
Tylko jeśli wyraźnie zezwolą Państwo na to źródło. Według dokumentacji Ubuntu nie wystarczy dodać repozytorium; musi ono dodatkowo znajdować się na liście dozwolonych źródeł pochodzenia unattended-upgrades.
Czy automatyka podnosi też PHP 8.2 do 8.3?
Nie. Automatyczne aktualizacje zabezpieczeń pozostają w obrębie zainstalowanych wersji pakietów. Zmiana głównej wersji PHP, na przykład przed końcem wsparcia dla PHP 8.2 w dniu 31.12.2026, pozostaje planowanym projektem z testami.
A co z kontenerami Docker?
Aktualizacje na hoście nie aktualizują wersji PHP w kontenerach. Obrazy kontenerów trzeba zbudować od nowa lub pobrać na nowo, a kontenery utworzyć ponownie.