Automatické bezpečnostní aktualizace na serverech s Linuxem

Stručně: Pomocí unattended-upgrades v Debianu a Ubuntu a dnf-automatic v rodině RHEL nasazují servery s Linuxem bezpečnostní aktualizace samy. Aby aktualizace také zabrala, musí se dotčené služby jako PHP-FPM poté restartovat; ověřte to pomocí needrestart nebo časů spuštění procesů. Zdroje třetích stran jako sury.org je třeba výslovně povolit, kontejnery a změny hlavní verze automatika nepokrývá.

Od záplaty na server: automatika šetří čas

Když php.net 21. října 2026 v 16:00 německého času zveřejnil záplaty proti PHP2Shell, začal pro správce závod. Podle zpráv distribuce své backporty dodávaly zčásti ještě týž den. Servery s automatickými bezpečnostními aktualizacemi mohly nové balíčky nainstalovat při nejbližším plánovaném běhu, aniž by musel někdo zasahovat.

To je dobrá zpráva. Méně dobrá: nainstalováno neznamená účinné. Služba PHP-FPM, která běží týdny, pracuje dál se starým kódem v paměti, dokud se nerestartuje. A balíčky ze zdrojů třetích stran, kontejnery nebo hostingové panely s vlastní správou PHP automatika často nechá nedotčené.

Tento článek ukazuje, jak nastavit automatické bezpečnostní aktualizace a doplnit je tak, aby v ostrém případě skutečně chránily.

unattended-upgrades v Debianu a Ubuntu

V Ubuntu je balíček unattended-upgrades standardně nainstalován a nasazuje bezpečnostní aktualizace. V Debianu jej v případě potřeby doinstalujete. Řídí se dvěma soubory pod /etc/apt/apt.conf.d/.

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Soubor 20auto-upgrades určuje, zda a jak často se aktualizují seznamy balíčků a nasazují aktualizace. Hodnota je počet dnů, "1" znamená denně:

// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

V 50unattended-upgrades je uvedeno, z jakých zdrojů smějí aktualizace pocházet, zda se poté restartuje a kdo dostane zprávu. Standardně jsou povoleny jen oficiální bezpečnostní zdroje distribuce. Podle dokumentace Ubuntu nestačí zapojit další repozitář: musí navíc stát v tomto seznamu, jinak jej automatika ignoruje. Týká se to například repozitáře třetí strany sury.org, který podle zpráv poskytoval buildy PHP pro všechny větve od 5.6 do 8.5. Pozadí je v článku Repozitář sury.org.

Zda je všechno v pořádku, ukáže zkušební běh, který nic nemění:

sudo unattended-upgrade -v --dry-run
# Protokoly skutečných běhů
ls -l /var/log/unattended-upgrades/

dnf-automatic v RHEL, AlmaLinux a Rocky Linux

V rodině RHEL přebírá stejný úkol dnf-automatic. Konfigurace leží v /etc/dnf/automatic.conf. Podle dokumentace upgrade_type = security kontroluje jen aktualizace s bezpečnostním upozorněním a apply_updates je standardně vypnuto.

# /etc/dnf/automatic.conf (výňatek)
[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*'

Vedle dnf-automatic.timer, který se řídí konfiguračním souborem, existují časovače, které jen hlásí, jen stahují nebo vždy instalují. Pro začátek je časovač s konfiguračním souborem nejlépe srozumitelný.

Podceňovaná část: restart služeb

Správce balíčků nahrazuje soubory na disku. Běžící procesy si ponechávají starý kód v paměti. U PHP to znamená: dokud PHP-FPM nebo Apache s mod_php nejsou restartovány, zůstává zranitelnost otevřená.

Podle dokumentace Ubuntu běží služby, které jsou z needrestart vyloučeny, až do ručního restartu se starými soubory. Po každé aktualizaci PHP proto zkontrolujte čas spuštění procesů, jak je popsáno v článku Restart PHP-FPM a všech workerů.

Co automatika nepokrývá

Automatické aktualizace jsou stavební kámen, ne úplná správa záplat. Některé oblasti potřebují vlastní postupy:

1. Kontejnery: PHP v imagích Dockeru se aktualizacemi hostitele neaktualizuje. Image znovu sestavit, kontejnery znovu vytvořit.
2. Hostingové panely: Plesk, cPanel a podobné panely spravují PHP zčásti přes vlastní balíčky a mechanismy.
3. Hlavní verze: Přechod například z PHP 8.2, které dosáhne konce podpory 31. 12. 2026, na novější verzi se automaticky neděje.
4. Aplikace: CMS, pluginy a závislosti Composeru mají vlastní cesty aktualizací.
5. Kontrola: Někdo musí číst protokoly a chybová hlášení automatiky. Potichu selhávající běh je horší než žádný, protože předstírá bezpečí.

Jak tyto části srůstají v proces, popisuje Správa záplat jako proces místo hašení požárů.

Závěr: automatika ano, slepá důvěra ne

Automatické bezpečnostní aktualizace patří na každý server s Linuxem dostupný z internetu. PHP2Shell ukázalo, jak málo času může zbýt: podle zpráv médií byl první pokus o útok pozorován už 17. října, čtyři dny před záplatami. Kdo poté stále čeká na ruční servisní okno, ztrácí cenný čas.

Automatika vám však odebírá jen nasazení. Restart služeb, doložení stavu záplat, kontejnery, panely a včasný přechod na podporované verze zůstávají úkoly, za které musí někdo odpovídat. Určete tuto odpovědnost písemně a namátkou kontrolujte, zda se protokoly automatiky skutečně čtou. Teprve kombinace automatiky a kontroly činí aktualizace spolehlivými.

Jak konkrétně pomáhá PHP SOS?

• Nastavit: Nakonfigurujeme unattended-upgrades nebo dnf-automatic podle vašich serverů, včetně povolených zdrojů třetích stran.
• Zajistit restarty: Zavedeme needrestart nebo odpovídající kontroly a po aktualizacích PHP ověřujeme časy spuštění procesů.
• Uzavřít mezery: Kontejnery, panely a změny hlavní verze zařadíme do pevného servisního postupu.
• Kontrolovat: V rámci smlouvy o bezpečnostní údržbě kontrolujeme protokoly automatiky a hlásíme nápadnosti.

Časté dotazy

Zdroje

• Ubuntu Server: automatické aktualizace
• DNF Automatic
• Debian Security Tracker
• Ubuntu Security Notices