Īsi sakot: Ar unattended-upgrades zem Debian un Ubuntu, kā arī dnf-automatic RHEL saimē Linux serveri drošības atjauninājumus ievieš paši. Lai atjauninājums darbotos, skartajiem pakalpojumiem, piemēram, PHP-FPM, pēc tam jāpārstartējas; pārbaudiet to ar needrestart vai procesu startēšanas laikiem. Trešo pušu avoti, piemēram, sury.org, jāatļauj nepārprotami, konteineru un galveno versiju maiņu automātika neaptver.
No ielāpa līdz serverim: automātika ietaupa laiku
Kad php.net 2026. gada 21. oktobrī plkst. 16:00 pēc Vācijas laika publicēja ielāpus pret PHP2Shell, administratoriem sākās sacensība. Saskaņā ar ziņojumiem distributīvi savus backport dažkārt piegādāja jau tajā pašā dienā. Serveri ar automātiskiem drošības atjauninājumiem jaunās pakotnes varēja instalēt nākamajā plānotajā palaišanā, kādam neiejaucoties.
Tā ir labā ziņa. Mazāk labā: instalēts nenozīmē darbojas. PHP-FPM pakalpojums, kas darbojas jau nedēļām, ar veco kodu atmiņā turpina strādāt, līdz tiek pārstartēts. Un pakotnes no trešo pušu avotiem, konteineri vai hostinga paneļi ar savu PHP pārvaldību automātikai bieži paliek neskarti.
Šis raksts rāda, kā ieviest automātiskus drošības atjauninājumus un tā papildināt, lai tie nopietnā situācijā patiešām aizsargā.
unattended-upgrades zem Debian un Ubuntu
Zem Ubuntu pakotne unattended-upgrades pēc noklusējuma ir instalēta un ievieš drošības atjauninājumus. Zem Debian to pēc vajadzības instalējat papildus. Tā tiek vadīta ar diviem failiem zem /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Fails 20auto-upgrades nosaka, vai un cik bieži tiek atjaunināti pakotņu saraksti un ieviesti atjauninājumi. Vērtība ir dienu skaits, "1" nozīmē katru dienu:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Failā 50unattended-upgrades ir norādīts, no kādiem avotiem atjauninājumi drīkst nākt, vai pēc tam tiek pārstartēts un kas saņem ziņojumu. Pēc noklusējuma atļauti ir tikai distributīva oficiālie drošības avoti. Saskaņā ar Ubuntu dokumentāciju nepietiek ar vēl viena repozitorija iekļaušanu: tam papildus jābūt šajā sarakstā, citādi automātika to ignorē. Tas attiecas, piemēram, uz trešās puses repozitoriju sury.org, kas saskaņā ar ziņojumiem piegādājis PHP būvējumus visiem zariem no 5.6 līdz 8.5. Fona informācija atrodama rakstā sury.org repozitorijs.
Vai viss kārtībā, parāda mēģinājuma palaišana, kas neko nemaina:
sudo unattended-upgrade -v --dry-run
# Īsto palaišanu protokoli
ls -l /var/log/unattended-upgrades/
dnf-automatic RHEL, AlmaLinux un Rocky Linux
RHEL saimē dnf-automatic pilda to pašu uzdevumu. Konfigurācija atrodas /etc/dnf/automatic.conf. Saskaņā ar dokumentāciju upgrade_type = security pārbauda tikai atjauninājumus ar drošības norādi, un apply_updates pēc noklusējuma ir izslēgts.
# /etc/dnf/automatic.conf (izvilkums)
[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*'
Līdzās dnf-automatic.timer, kas seko konfigurācijas failam, ir taimeri, kas tikai ziņo, tikai lejupielādē vai vienmēr instalē. Sākumam taimeris ar konfigurācijas failu ir visizsekojamākais.
Nenovērtētā daļa: pakalpojumu pārstartēšana
Pakotņu pārvaldnieks aizstāj failus diskā. Darbojošies procesi atmiņā saglabā veco kodu. PHP gadījumā tas nozīmē: kamēr PHP-FPM vai Apache ar mod_php nav pārstartēti, ievainojamība paliek atvērta.
| Rīks | Sistēma | Ko tas dara |
|---|---|---|
| needrestart | Debian, Ubuntu | atpazīst pakalpojumus ar novecojušiem failiem; zem Ubuntu no 24.04 pēc noklusējuma tos pārstartē automātiski |
dnf needs-restarting -s |
RHEL saime | uzskaita pakalpojumus, kas jāpārstartē |
Automatic-Reboot |
unattended-upgrades | pārstartē serveri, ja atjauninājums to prasa; pēc noklusējuma izslēgts |
reboot |
dnf-automatic | never, when-changed vai when-needed |
Saskaņā ar Ubuntu dokumentāciju pakalpojumi, kas needrestart ir izņemti, līdz manuālai pārstartēšanai turpina darboties ar vecajiem failiem. Pēc katra PHP atjauninājuma tāpēc pārbaudiet procesu startēšanas laiku, kā aprakstīts sadaļā PHP-FPM un visu worker procesu pārstartēšana.
Backport gadījumā parādītais PHP versijas numurs bieži paliek tas pats. Ielāpu pierādiet ar pakotnes changelog ar CVE numuriem, piemēram, ar apt-get changelog vai rpm -q --changelog. Kā tas darbojas detalizēti, rāda Debian un Ubuntu: vai mana PHP pakotne ir ielāpota?.
Ko automātika neaptver
Automātiski atjauninājumi ir viens elements, nevis pilnīga ielāpu pārvaldība. Dažām jomām vajadzīgi savi procesi:
- Konteineri: PHP Docker attēlos resursdatora atjauninājumi neatjaunina. Attēlus pārbūvēt, konteinerus izveidot no jauna.
- Hostinga paneļi: Plesk, cPanel un līdzīgi paneļi PHP daļēji pārvalda ar savām pakotnēm un mehānismiem.
- Galvenās versijas: pāreja, piemēram, no PHP 8.2, kas 2026. gada 31. decembrī sasniedz atbalsta beigas, uz jaunāku versiju nenotiek automātiski.
- Lietojumprogrammas: CMS, spraudņiem un Composer atkarībām ir savi atjaunināšanas ceļi.
- Kontrole: kādam jāizlasa automātikas protokoli un kļūdu ziņojumi. Klusi izgāzusies palaišana ir sliktāka par nevienu, jo tā simulē drošību.
Kā šīs daļas saaug procesā, apraksta Ielāpu pārvaldība kā process, nevis ugunsdzēsība.
Secinājums: automātika jā, akla uzticēšanās nē
Automātiski drošības atjauninājumi pieder katram Linux serverim, kas sasniedzams no interneta. PHP2Shell ir parādījusi, cik šaurs var kļūt laiks: saskaņā ar plašsaziņas līdzekļu ziņojumiem pirmais uzbrukuma mēģinājums tika novērots jau 17. oktobrī, četras dienas pirms ielāpiem. Kas pēc tam vēl gaida manuālu uzturēšanas logu, tas zaudē vērtīgu laiku.
Automātika jums noņem tikai ieviešanu. Pakalpojumu pārstartēšana, ielāpu stāvokļa pierādījums, konteineri, paneļi un savlaicīga pāreja uz atbalstītām versijām paliek uzdevumi, par kuriem kādam jābūt atbildīgam. Noteiciet šo atbildību rakstiski un izlases veidā pārbaudiet, vai automātikas protokoli patiešām tiek lasīti. Tikai automātikas un kontroles kombinācija atjauninājumus dara uzticamus.
Kā PHP SOS palīdz konkrēti?
- Ieviest: mēs konfigurējam unattended-upgrades vai dnf-automatic atbilstoši jūsu serveriem, ieskaitot atļautos trešo pušu avotus.
- Nodrošināt pārstartēšanas: mēs ieviešam needrestart vai atbilstošas pārbaudes un pēc PHP atjauninājumiem kontrolējam procesu startēšanas laikus.
- Aizvērt robus: konteinerus, paneļus un galveno versiju maiņu mēs iekļaujam fiksētā uzturēšanas procesā.
- Kontrolēt: drošības uzturēšanas līgumā mēs pārbaudām automātikas protokolus un ziņojam par uzkrītošo.
Biežāk uzdotie jautājumi
Vai automātiski atjauninājumi produkcijas serveros nav pārāk riskanti?
Ierobežoti uz distributīva drošības atjauninājumiem risks parasti ir mazāks nekā atvērtas ievainojamības risks. Šiem atjauninājumiem nav jānes jaunas funkcijas, bet jālabo kļūdas. Kritiskām sistēmām klāt pieder rezerves kopijas, uzraudzība un testa sistēma.
Vai unattended-upgrades pēc atjauninājuma pārstartē PHP-FPM?
Ne obligāti pats. Zem Ubuntu no versijas 24.04 rīks needrestart skartos pakalpojumus pēc noklusējuma pārstartē automātiski, bet izņēmuma pakalpojumi turpina darboties ar vecajiem failiem. Pēc katra PHP atjauninājuma pārbaudiet visu PHP procesu startēšanas laiku.
Vai pakotnes no sury.org vai citiem trešo pušu avotiem tiek atjauninātas automātiski?
Tikai tad, ja avotu nepārprotami atļaujat. Saskaņā ar Ubuntu dokumentāciju nepietiek ar repozitorija pievienošanu; tam papildus jābūt unattended-upgrades atļauto izcelsmju sarakstā.
Vai automātika paaugstina arī PHP 8.2 uz 8.3?
Nē. Automātiski drošības atjauninājumi paliek uzstādīto pakotņu versiju robežās. PHP galvenās versijas maiņa, piemēram, pirms PHP 8.2 atbalsta beigām 2026. gada 31. decembrī, paliek plānots projekts ar testiem.
Kā ar Docker konteineriem?
Atjauninājumi resursdatorā PHP versiju konteineros neatjaunina. Konteineru attēli jāpārbūvē vai jāpārvelk un konteineri jāizveido no jauna.