Trumpai: su unattended-upgrades Debian ir Ubuntu sistemose bei dnf-automatic RHEL šeimoje Linux serveriai saugumo atnaujinimus diegia patys. Kad atnaujinimas veiktų, po to paveiktos paslaugos, tokios kaip PHP-FPM, turi būti paleistos iš naujo; patikrinkite tai su needrestart arba procesų paleidimo laikais. Trečiųjų šalių šaltiniai, tokie kaip sury.org, turi būti aiškiai leidžiami, konteinerių ir pagrindinių versijų keitimo automatika neapima.
Nuo pataisos iki serverio: automatika taupo laiką
Kai php.net 2026 m. spalio 21 d. 16 val. Vokietijos laiku paskelbė pataisas nuo PHP2Shell, administratoriams prasidėjo lenktynės. Pasak pranešimų, distribucijos savo atgalinius pataisų perkėlimus (backport) kartais pateikė tą pačią dieną. Serveriai su automatiniais saugumo atnaujinimais naujus paketus galėjo įdiegti per kitą planinį paleidimą, niekam nesikišant.
Tai gera žinia. Ne tokia gera: įdiegta nereiškia veiksminga. PHP-FPM paslauga, veikianti jau savaitėmis, toliau dirba su senu kodu atmintyje, kol bus paleista iš naujo. O paketai iš trečiųjų šalių šaltinių, konteineriai ar hostingo skydeliai su savu PHP valdymu automatikos dažnai lieka neliečiami.
Šis straipsnis parodo, kaip įrengti automatinius saugumo atnaujinimus ir juos papildyti taip, kad kritiniu atveju jie tikrai saugotų.
unattended-upgrades Debian ir Ubuntu
Ubuntu paketas unattended-upgrades numatytai įdiegtas ir diegia saugumo atnaujinimus. Debian prireikus jį įdiegiate papildomai. Valdoma per du failus aplanke /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Failas 20auto-upgrades nustato, ar ir kaip dažnai atnaujinami paketų sąrašai ir diegiami atnaujinimai. Reikšmė yra dienų skaičius, "1" reiškia kasdien:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
50unattended-upgrades nurodo, iš kokių šaltinių gali ateiti atnaujinimai, ar po to paleidžiama iš naujo ir kas gauna pranešimą. Numatytai leidžiami tik oficialūs distribucijos saugumo šaltiniai. Pasak Ubuntu dokumentacijos, nepakanka prijungti kitą saugyklą (repository): ji papildomai turi būti šiame sąraše, kitaip automatika ją ignoruoja. Tai liečia, pavyzdžiui, trečiosios šalies saugyklą sury.org, kuri, pasak pranešimų, teikė PHP versijas visoms šakoms nuo 5.6 iki 8.5. Kontekstas pateiktas straipsnyje sury.org saugykla.
Ar viskas teisinga, parodo bandomasis paleidimas, nieko nekeičiantis:
sudo unattended-upgrade -v --dry-run
# Tikrų paleidimų žurnalai
ls -l /var/log/unattended-upgrades/
dnf-automatic RHEL, AlmaLinux ir Rocky Linux
RHEL šeimoje tą pačią užduotį atlieka dnf-automatic. Konfigūracija yra /etc/dnf/automatic.conf. Pasak dokumentacijos, upgrade_type = security tikrina tik atnaujinimus su saugumo pranešimu, o apply_updates numatytai išjungtas.
# /etc/dnf/automatic.conf (ištrauka)
[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*'
Be dnf-automatic.timer, kuris seka konfigūracijos failą, yra laikmačių, kurie tik praneša, tik atsisiunčia arba visada diegia. Pradžiai laikmatis su konfigūracijos failu aiškiausias.
Nepakankamai vertinama dalis: paslaugų paleidimas iš naujo
Paketų valdymas pakeičia failus diske. Veikiantys procesai atmintyje išlaiko seną kodą. PHP atveju tai reiškia: kol PHP-FPM arba Apache su mod_php nėra paleisti iš naujo, spraga lieka atvira.
| Įrankis | Sistema | Ką daro |
|---|---|---|
| needrestart | Debian, Ubuntu | atpažįsta paslaugas su pasenusiais failais; Ubuntu nuo 24.04 numatytai paleidžia jas iš naujo automatiškai |
dnf needs-restarting -s |
RHEL šeima | išvardija paslaugas, kurias reikėtų paleisti iš naujo |
Automatic-Reboot |
unattended-upgrades | paleidžia serverį iš naujo, kai to reikalauja atnaujinimas; numatytai išjungta |
reboot |
dnf-automatic | never, when-changed arba when-needed |
Pasak Ubuntu dokumentacijos, paslaugos, kurias needrestart išskyrė iš sąrašo, iki rankinio paleidimo iš naujo veikia su senais failais. Todėl po kiekvieno PHP atnaujinimo patikrinkite procesų paleidimo laiką, kaip aprašyta skyriuje PHP-FPM ir visų darbinių procesų paleidimas iš naujo.
Esant atgaliniams pataisų perkėlimams (backport), rodomas PHP versijos numeris dažnai lieka tas pats. Pataisą įrodote per paketo pakeitimų žurnalą su CVE numeriais, pavyzdžiui, su apt-get changelog arba rpm -q --changelog. Kaip tai daroma išsamiai, rodo Debian ir Ubuntu: ar mano PHP paketas pataisytas?.
Ko automatika neapima
Automatiniai atnaujinimai yra viena dalis, o ne pilnas pataisų valdymas. Kai kurioms sritims reikia savų eigų:
- Konteineriai: PHP Docker atvaizduose pagrindinio kompiuterio atnaujinimais neatnaujinamas. Atvaizdus perkurti, konteinerius sukurti iš naujo.
- Hostingo skydeliai: Plesk, cPanel ir panašūs skydeliai PHP iš dalies valdo per savus paketus ir mechanizmus.
- Pagrindinės versijos: perėjimas, pavyzdžiui, nuo PHP 8.2, kurio palaikymas baigiasi 2026-12-31, prie naujesnės versijos nevyksta automatiškai.
- Programos: CMS, papildiniai ir Composer priklausomybės turi savus atnaujinimo kelius.
- Kontrolė: kas nors turi skaityti automatikos žurnalus ir klaidų pranešimus. Tyliai nepavykęs paleidimas yra blogesnis nei jokio, nes apgaulingai sukuria saugumo įspūdį.
Kaip šios dalys susijungia į procesą, aprašo Pataisų valdymas kaip procesas, o ne gaisrininkų darbas.
Išvada: automatika taip, aklas pasitikėjimas ne
Automatiniai saugumo atnaujinimai priklauso kiekvienam iš interneto pasiekiamam Linux serveriui. PHP2Shell parodė, kaip trumpas gali tapti laikas: pasak žiniasklaidos pranešimų, pirmasis atakos bandymas pastebėtas jau spalio 17 d., keturiomis dienomis prieš pataisas. Kas po to dar laukia rankinio priežiūros lango, praranda vertingą laiką.
Tačiau automatika nuima nuo jūsų tik diegimą. Paslaugų paleidimas iš naujo, pataisų būsenos įrodymas, konteineriai, skydeliai ir savalaikis perėjimas prie palaikomų versijų lieka užduotimis, už kurias kas nors turi atsakyti. Šią atsakomybę nustatykite raštu ir atrankos būdu tikrinkite, ar automatikos žurnalai iš tikrųjų skaitomi. Tik automatikos ir kontrolės derinys atnaujinimus daro patikimus.
Kaip PHP SOS padeda konkrečiai?
- Įrengti: sukonfigūruojame unattended-upgrades arba dnf-automatic pagal jūsų serverius, įskaitant leidžiamus trečiųjų šalių šaltinius.
- Užtikrinti paleidimus iš naujo: įrengiame needrestart ar atitinkamas patikras ir po PHP atnaujinimų kontroliuojame procesų paleidimo laikus.
- Uždaryti spragas: konteinerius, skydelius ir pagrindinių versijų keitimą įtraukiame į fiksuotą priežiūros eigą.
- Kontroliuoti: saugumo priežiūros sutartyje tikriname automatikos žurnalus ir pranešame apie įtartinus atvejus.
Dažni klausimai
Ar automatiniai atnaujinimai produkciniuose serveriuose nėra per rizikingi?
Apsiribojus distribucijos saugumo atnaujinimais, rizika dažniausiai mažesnė nei atviros spragos. Šie atnaujinimai neturi atnešti naujų funkcijų, o taisyti klaidas. Kritinėms sistemoms priklauso atsarginės kopijos, stebėsena ir testinė sistema.
Ar unattended-upgrades po atnaujinimo iš naujo paleidžia PHP-FPM?
Nebūtinai pats. Ubuntu nuo 24.04 versijos įrankis needrestart numatytai automatiškai paleidžia iš naujo paveiktas paslaugas, tačiau išimtys veikia toliau su senais failais. Po kiekvieno PHP atnaujinimo patikrinkite visų PHP procesų paleidimo laiką.
Ar paketai iš sury.org ar kitų trečiųjų šalių šaltinių atnaujinami automatiškai?
Tik jei šaltinį aiškiai leidžiate. Pasak Ubuntu dokumentacijos, nepakanka pridėti saugyklą (repository); ji papildomai turi būti unattended-upgrades leidžiamų kilmių sąraše.
Ar automatika PHP 8.2 pakelia iki 8.3?
Ne. Automatiniai saugumo atnaujinimai lieka įdiegtų paketų versijose. PHP pagrindinės versijos keitimas, pavyzdžiui, prieš PHP 8.2 palaikymo pabaigą 2026-12-31, lieka suplanuotas projektas su bandymais.
O kaip su Docker konteineriais?
Pagrindinio kompiuterio (host) atnaujinimai PHP versijos konteineriuose neatnaujina. Konteinerių atvaizdus reikia perkurti arba iš naujo parsisiųsti ir konteinerius sukurti iš naujo.