Röviden: A Debianon és Ubuntun az unattended-upgrades-szel, az RHEL-családban a dnf-automatic-kal a Linux-szerverek önállóan telepítik a biztonsági frissítéseket. Hogy egy frissítés hasson is, az érintett szolgáltatásokat, például a PHP-FPM-et, utána újra kell indítani; ezt a needrestarttal vagy a folyamatok indítási idejével ellenőrizze. A külső forrásokat, például a sury.org-ot, kifejezetten engedélyezni kell, a konténereket és a főverzió-váltásokat az automatika nem fedi le.
A javítástól a szerverig: az automatika időt takarít meg
Amikor a php.net 2026. október 21-én német idő szerint 16 órakor közzétette a PHP2Shell elleni javításokat, versenyfutás kezdődött az adminisztrátorok számára. Beszámolók szerint a disztribúciók a backportokat részben még ugyanazon a napon kiszállították. Az automatikus biztonsági frissítésekkel rendelkező szerverek az új csomagokat a következő ütemezett futásnál telepíthették anélkül, hogy bárkinek közbe kellett volna lépnie.
Ez a jó hír. A kevésbé jó: telepítve nem jelent hatékonyt. Egy hetek óta futó PHP-FPM-szolgáltatás a régi kóddal dolgozik tovább a memóriában, amíg újra nem indítják. A külső forrásokból származó csomagokat, a konténereket vagy a saját PHP-kezeléssel rendelkező tárhelypaneleket az automatika gyakran érintetlenül hagyja.
Ez a cikk megmutatja, hogyan állítson be automatikus biztonsági frissítéseket, és hogyan egészítse ki őket úgy, hogy éles helyzetben valóban védjenek.
Az unattended-upgrades Debianon és Ubuntun
Ubuntun az unattended-upgrades csomag alapértelmezetten telepítve van, és biztonsági frissítéseket telepít. Debianon szükség esetén utólag telepítse. Két fájlon keresztül vezérelhető az /etc/apt/apt.conf.d/ alatt.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
A 20auto-upgrades fájl határozza meg, hogy frissítik-e a csomaglistákat és telepítik-e a frissítéseket, és milyen gyakran. Az érték a napok száma, az "1" naponta jelent:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Az 50unattended-upgrades fájlban áll, mely forrásokból származhatnak frissítések, újraindítanak-e utána, és ki kap értesítést. Alapértelmezetten csak a disztribúció hivatalos biztonsági forrásai vannak engedélyezve. Az Ubuntu dokumentációja szerint nem elég egy további repositoryt beágyazni: ezenkívül szerepelnie kell ebben a listában, különben az automatika figyelmen kívül hagyja. Ez érinti például a harmadik féltől származó sury.org repositoryt, amely beszámolók szerint az 5.6-tól a 8.5-ig minden ághoz biztosított PHP-buildeket. A hátterekről a A sury.org repository cikk szól.
Hogy minden rendben van-e, azt egy próbafutás mutatja, amely nem módosít semmit:
sudo unattended-upgrade -v --dry-run
# Az éles futások naplói
ls -l /var/log/unattended-upgrades/
A dnf-automatic RHEL-en, AlmaLinuxon és Rocky Linuxon
Az RHEL-családban a dnf-automatic ugyanezt a feladatot látja el. A konfiguráció az /etc/dnf/automatic.conf fájlban van. A dokumentáció szerint az upgrade_type = security csak biztonsági közleménnyel rendelkező frissítéseket ellenőriz, és az apply_updates alapértelmezetten ki van kapcsolva.
# /etc/dnf/automatic.conf (részlet)
[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*'
A konfigurációs fájlt követő dnf-automatic.timer mellett vannak olyan timerek, amelyek csak jeleznek, csak letöltenek, vagy mindig telepítenek. Az induláshoz a konfigurációs fájlos timer a legjobban átlátható.
Az alulbecsült rész: a szolgáltatások újraindítása
A csomagkezelő fájlokat cserél a merevlemezen. A futó folyamatok megtartják a régi kódot a memóriában. A PHP-nál ez azt jelenti: amíg a PHP-FPM-et vagy az Apache-ot mod_php-val nem indítják újra, a rés nyitva marad.
| Eszköz | Rendszer | Mit csinál |
|---|---|---|
| needrestart | Debian, Ubuntu | felismeri az elavult fájlokkal rendelkező szolgáltatásokat; Ubuntun a 24.04-től alapértelmezetten automatikusan újraindítja őket |
dnf needs-restarting -s |
RHEL-család | felsorolja azokat a szolgáltatásokat, amelyeket újra kellene indítani |
Automatic-Reboot |
unattended-upgrades | újraindítja a szervert, ha egy frissítés megköveteli; alapértelmezetten ki van kapcsolva |
reboot |
dnf-automatic | never, when-changed vagy when-needed |
Az Ubuntu dokumentációja szerint a needrestart által kivételként kezelt szolgáltatások a kézi újraindításig régi fájlokkal futnak tovább. Ezért minden PHP-frissítés után ellenőrizze a folyamatok indítási idejét, ahogyan a PHP-FPM és az összes worker újraindítása leírja.
Backportoknál a kijelzett PHP-verziószám gyakran ugyanaz marad. A javítást a CVE-számokat tartalmazó csomag-changelogon keresztül igazolja, például az apt-get changelog vagy az rpm -q --changelog paranccsal. Hogyan megy ez részletesen, azt a Debian és Ubuntu: javított-e a PHP-csomagom? mutatja.
Amit az automatika nem fed le
Az automatikus frissítések egy építőelemek, nem teljes javításkezelés. Néhány terület saját folyamatot igényel:
- Konténerek: A Docker-image-ekben lévő PHP-t a hoszton végzett frissítések nem frissítik. Az image-eket újra kell építeni, a konténereket újra létrehozni.
- Tárhelypanelek: A Plesk, a cPanel és hasonló panelek a PHP-t részben saját csomagokon és mechanizmusokon keresztül kezelik.
- Főverziók: A váltás például a PHP 8.2-ről, amely 2026. 12. 31-én éri el a támogatás végét, egy újabb verzióra nem történik automatikusan.
- Alkalmazások: A CMS-eknek, pluginoknak és Composer-függőségeknek saját frissítési útjaik vannak.
- Ellenőrzés: Valakinek olvasnia kell az automatika naplóit és hibaüzeneteit. Egy csendben meghiúsuló futás rosszabb, mint egy sem, mert biztonságot színlel.
Hogyan áll össze ezekből a részekből egy folyamat, azt a Javításkezelés folyamatként, nem tűzoltásként írja le.
Összegzés: automatika igen, vak bizalom nem
Az automatikus biztonsági frissítések minden, az internetről elérhető Linux-szerverre valók. A PHP2Shell megmutatta, mennyire szűkössé válhat az idő: médiabeszámolók szerint az első támadási kísérletet már október 17-én megfigyelték, négy nappal a javítások előtt. Aki ezután még kézi karbantartási ablakra vár, értékes időt veszít.
Az automatika azonban csak a telepítést veszi le Önről. A szolgáltatások újraindítása, a javítási állapot igazolása, a konténerek, a panelek és az időben végzett váltás támogatott verziókra olyan feladatok maradnak, amelyekért valakinek felelnie kell. Rögzítse írásban ezt a felelősséget, és szúrópróbaszerűen ellenőrizze, hogy az automatika naplóit tényleg olvassák-e. Csak az automatika és az ellenőrzés kombinációja teszi megbízhatóvá a frissítéseket.
Hogyan segít konkrétan a PHP SOS?
- Beállítás: Az unattended-upgrades vagy a dnf-automatic konfigurálása a szervereihez illően, az engedélyezett külső forrásokkal együtt.
- Az újraindítások biztosítása: Beállítjuk a needrestartot vagy megfelelő ellenőrzéseket, és a PHP-frissítések után ellenőrizzük a folyamatok indítási idejét.
- A hézagok lezárása: A konténereket, panelokat és főverzió-váltásokat rögzített karbantartási folyamatba vesszük.
- Ellenőrzés: A biztonsági karbantartási szerződés keretében ellenőrizzük az automatika naplóit, és jelezzük a feltűnéseket.
Gyakori kérdések
Az automatikus frissítések nem túl kockázatosak éles szervereken?
A disztribúció biztonsági frissítéseire korlátozva a kockázat többnyire kisebb, mint egy nyitva hagyott résé. Ezek a frissítések nem új funkciókat hoznak, hanem hibákat javítanak. A kritikus rendszerekhez mentések, felügyelet és egy tesztrendszer tartozik.
Újraindítja az unattended-upgrades a PHP-FPM-et egy frissítés után?
Nem feltétlenül maga. Ubuntun a 24.04-es verziótól a needrestart eszköz alapértelmezetten automatikusan újraindítja az érintett szolgáltatásokat, a kivételként kezelt szolgáltatások azonban régi fájlokkal futnak tovább. Minden PHP-frissítés után ellenőrizze az összes PHP-folyamat indítási idejét.
Automatikusan frissülnek a sury.org vagy más külső források csomagjai?
Csak ha a forrást kifejezetten engedélyezi. Az Ubuntu dokumentációja szerint nem elég egy repository hozzáadása; ezenkívül szerepelnie kell az unattended-upgrades engedélyezett eredetek listájában.
Az automatika a PHP 8.2-t 8.3-ra is emeli?
Nem. Az automatikus biztonsági frissítések a telepített csomagverziókon belül maradnak. A PHP főverziójának váltása, például a PHP 8.2 támogatásának 2026. 12. 31-i vége előtt, tesztekkel járó, tervezett projekt marad.
Mi a helyzet a Docker-konténerekkel?
A hoszton végzett frissítések nem frissítik a konténerekben lévő PHP-verziót. A konténer-image-eket újra kell építeni vagy újra le kell tölteni, és a konténereket újra kell létrehozni.