Īsi: Kas pats pārvalda root serveri vai vServer, tam pēc PHP2Shell tas arī pašam jānodrošina: PHP pakotnes jānovieto labotā stāvoklī, jāpārstartē visi PHP procesi un jāpārbauda rezultāts. Datu centra operators parasti rūpējas tikai par aparatūru, virtualizāciju un tīklu. Pēc tam ir vērts serveri ilgtermiņā nostiprināt.
Jūsu atbildība par savu serveri
Nepārvaldīta root servera vai vServer gadījumā jūs īrējat skaitļošanas jaudu, nevis apkalpošanu. Operētājsistēma, tīmekļa serveris, PHP, datubāze, ugunsmūris, rezerves kopijas un uzraudzība ir jūsu rokās. Vadībai un īpašniekiem tas nozīmē: ja neviens uzņēmumā vai pie pakalpojumu sniedzēja šos uzdevumus nav skaidri uzņēmies, tos nedara neviens.
PHP2Shell to padara redzamu. Abas ievainojamības CVE-2026-109618 un CVE-2026-109619 slēpjas pašā PHP un ļauj izpildīt kodu bez autentifikācijas. PHP projekts 2026. gada 21. oktobrī publicēja versijas 8.5.12, 8.4.27, 8.3.36 un 8.2.35. BSI iesaka nekavējoties atjaunināt un, ja tas nav iespējams, tīmekļa serveri uz laiku atvienot no tīkla.
vServer aizsardzība: pārbaudiet esošo un pakotņu stāvokli
Vispirms gūstiet pārskatu, kuras PHP versijas ir instalētas un no kāda avota tās nāk. Daudzi serveri līdzās distributīva pakotnēm izmanto papildu pakotņu avotus. Turpmākās komandas tikai lasa. Pakotņu nosaukumi ir piemēri.
# Debian/Ubuntu: instalētās PHP pakotnes un to izcelsme
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Kādi PHP binārie faili vispār ir?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Ar versijas numuru vien nepietiek. Distributīvi drošības labojumus bieži piegādā kā backportu, tad parādītais numurs paliek vecāks. Izšķirošs ir pakotnes izmaiņu žurnāls.
# Debian/Ubuntu (pakotnes nosaukums kā piemērs)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL saime (pakotnes nosaukums kā piemērs)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Detalizētu pamācību skatiet lapā PHP versijas un ielāpa stāvokļa pārbaude.
Atjauninājuma ieinstalēšana un visu procesu atjaunošana
Ieinstalējiet atjauninājumus ar pakotņu pārvaldību un pēc tam pārstartējiet katru pakalpojumu, kas ielādē PHP. Atkarībā no uzbūves tie ir PHP-FPM, Apache ar mod_php, LiteSpeed vai lietojumprogrammu serveris. Ar jauniem failiem diskā nepietiek, kamēr atmiņā darbojas veci procesi.
# Atrast pakalpojumus ar PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Parādīt procesus ar startēšanas laiku
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: atpazīt programmas ar novecojušām bibliotēkām (ja instalēts)
needrestart -r l
Katram attiecīgajam procesam jābūt startētam pēc atjauninājuma. Debian sistēmās noder rīks needrestart, kas parāda pakalpojumus ar novecojušām bibliotēkām. Sīkāk par pārstartēšanu skatiet lapā PHP-FPM un visu darbprocesu pārstartēšana.
Ielāps nenoņem ļaunprātīgu programmatūru, kas tika ievadīta pirms atjauninājuma. Saglabājiet tīmekļa servera žurnālus no 2026. gada 20. oktobra un pārbaudiet serveri, vai tajā nav pēdu, pirms atzīstat to par tīru.
Pirmajai pēdu meklēšanai der vairākas pārbaudes, kas neko nemaina. Meklējiet PHP failus, kas kopš 2026. gada 17. oktobra tīmekļa direktorijos ir izveidoti vai mainīti, nezināmus ierakstus visu lietotāju crontab, jaunus sistēmas lietotājus un SSH atslēgas, kā arī tīmekļa servera lietotāja procesus, kuri uztur izejošus savienojumus.
# Kopš 2026-10-17 mainītie PHP faili (ceļš kā piemērs)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Tīkla savienojumi ar attiecīgo procesu
ss -tupn
Neviena no šīm pārbaudēm pati par sevi neapliecina ielaušanos, un tukšs rezultāts neapliecina pretējo. Tomēr tās parāda, vai nepieciešama dziļāka izmeklēšana. Strādājiet ar žurnālu kopijām un nemainiet aizdomīgus failus, kamēr stāvoklis nav saglabāts. Atradumu gadījumā droša ir sakārtota izmeklēšana. Šādā gadījumā serveri vienkārši neizslēdziet un nepostiet uzreiz no jauna, jo tā tiek zaudētas pēdas, kas ir svarīgas ziņošanas pienākumu izvērtēšanai un iespējamam iesniegumam policijā.
Servera ilgtermiņa nostiprināšana
Pēc akūtā ielāpa seko pamata drošība. Tā nepasargā no katras ievainojamības, taču ierobežo kaitējumu un saīsina reaģēšanas laiku nākamreiz. Pierādījušies šādi punkti:
- Piekļuves: SSH tikai ar atslēgu, nekādas tiešas root pieteikšanās, pārvaldības saskarnes pieejamas tikai no zināmiem tīkliem.
- Ugunsmūris: atvērt tikai tos portus, kas patiešām nepieciešami, ierobežot tīmekļa servera izejošos savienojumus.
- PHP konfigurācija: atspējot bīstamās funkcijas,
open_basedirkatrai vietnei, atsevišķi pūli un lietotāji katrai lietojumprogrammai. - Failu tiesības: tīmekļa serveris nedrīkst rakstīt programmas kodā, augšupielāžu direktorijos PHP netiek izpildīts.
- Atjauninājumi: drošības atjauninājumus ieinstalēt automātiski, pārstartēšanu un kontroli ieplānot nemainīgi.
- Rezerves kopijas: kopijas pēc 3-2-1 noteikuma, vismaz viena kopija ārpus servera un pasargāta no izmaiņām.
- Žurnāli: žurnālus vākt centralizēti un glabāt pietiekami ilgi.
Kā izskatās noturīga rezerves kopija, apraksta lapa Rezerves kopijas pēc 3-2-1 noteikuma. Kā uzņēmumu ietvaru der izmantot BSI IT-Grundschutz.
Kad labāka izvēle ir pārvaldīts serveris
Savs serveris atmaksājas, ja kāds uzticami uzņemas tā uzturēšanu: seko atjauninājumiem, izvērtē tādas situācijas kā PHP2Shell, spēj reaģēt arī naktī. Ja šādas kapacitātes nav, jēga ir vai nu pārvaldītam serverim (Managed Server), vai fiksētam uzturēšanas līgumam. Abos gadījumos svarīgi atbildības jomas fiksēt rakstiski. Vairāk par to lapā Managed Server: atbildības noskaidrošana.
Kā PHP SOS palīdz konkrēti?
- Mēs uzskaitām visas jūsu servera PHP instalācijas, pakotņu avotus un pakalpojumus un novērtējam faktisko ielāpa stāvokli.
- Mēs ieinstalējam atjauninājumus, pārstartējam visus procesus un dokumentējam rezultātu.
- Mēs pārbaudām serveri, vai tajā nav kompromitēšanas pēdu, un saglabājam žurnālus vēlākai izvērtēšanai.
- Savas servera nostiprināšanas ietvaros mēs sakārtoti iestatām piekļuves, ugunsmūri, PHP pūlus un tiesības.
- Pēc vēlēšanās mēs uzņemamies pastāvīgu uzturēšanu ar drošības uzturēšanas līgumu.
Biežāk uzdotie jautājumi
Vai mana datu centra operators vServer ielāpo automātiski?
Nepārvaldītiem root serveriem un vServer parasti nē. Sniedzējs nodrošina aparatūru vai virtualizāciju un tīklu, bet operētājsistēmu un visus pakalpojumus uz tās pārvaldāt paši. Šaubu gadījumā pārbaudiet savu līgumu.
Vai pietiek ar automātiskiem drošības atjauninājumiem?
Tie palīdz, bet neaizstāj kontroli. Automātiskie atjauninājumi ne vienmēr pārstartē darbojošos PHP procesus un bieži neaptver pakotnes no trešo pušu avotiem. Pēc katra drošības atjauninājuma pārbaudiet pakotnes stāvokli un procesu startēšanas laiku.
Kā noskaidrot, vai manā pakotnē ir backports?
Pakotnes izmaiņu žurnālā un jūsu distributīva drošības paziņojumos. Ja tur ir CVE numurs, labojums ir iekļauts, pat ja versijas numurs šķiet vecāks. Ja ieraksta nav, noskaidrojiet stāvokli, pirms servera atzīstat par ielāpotu.
Ko darīt, ja manai PHP versijai ielāps nenāks?
PHP 8.1 un vecākām versijām oficiālu atjauninājumu vairs nav. Iestatiet pagaidu pasākumus saskaņā ar php.net, ātri plānojiet pāreju uz atbalstītu versiju un pēc BSI ieteikuma vajadzības gadījumā serveri uz laiku atvienojiet no tīkla.