Īsi sakot: PHP2Shell gadījumā laika logs starp ielāpu un uzbrukumu bija negatīvs: saskaņā ar mediju ziņojumiem pirmais uzbrukuma mēģinājums bija jau 2026. gada 17. oktobrī, četras dienas pirms atjauninājumiem. Operatoriem tāpēc svarīgs nav jautājums “Cik laika ir atlicis?”, bet “Cik ilgi mans serveris ir atvērts?”. Šis personīgais logs beidzas tikai tad, kad atjauninājums ir instalēts un visi PHP procesi ir pārstartēti.
Sākumpunkts: uzbrukumi pirms ielāpa
Ilgi valdīja ērts pieņēmums: starp drošības atjauninājumu un pirmajiem uzbrukumiem paiet dažas dienas, pietiekami nākamajam apkopes logam. PHP2Shell šo pieņēmumu atspēkoja. Saskaņā ar mediju ziņojumiem, kas atsaucas uz Amazon, pirmais uzbrukuma mēģinājums tika novērots jau 17. oktobrī. Cloudflare arī ziņoja par agrīniem uzbrukumiem. Ielāpi nāca 21. oktobrī plkst. 14:00 UTC.
Šis raksts izskaidro, kā rodas šādi laika logi un kā savējo saīsināt. Precīzu datumu secību atradīsiet PHP2Shell laika līnijā.
Laika logs starp ielāpu un uzbrukumu pa fāzēm
Ap drošības ievainojamību var nošķirt vairākas fāzes. PHP2Shell gadījumā tās izskatījās šādi:
| Fāze | Vispārīgi | PHP2Shell gadījumā |
|---|---|---|
| Pirms kļūšanas zināmai | ievainojamība zināma tikai atklājējiem un ražotājam | labojuma izstrāde zem embargo |
| Pirmie uzbrukumi bez ielāpa | uzbrucēji izmanto ievainojamību, pirms atjauninājums eksistē | saskaņā ar mediju ziņojumiem pirmais mēģinājums 17.10. |
| Iepriekšējs paziņojums | ražotājs paziņo par atjauninājumu | 20.10., php.net paziņo par laidienu |
| Ielāps pieejams | parādās atjauninājums un drošības paziņojums | 21.10., 14:00 UTC |
| Ielāpa izvērtēšana | pētnieki un uzbrucēji analizē izmaiņas | watchTowr pēc paša teiktā ir atveidojis CVE-2026-109618 |
| Plaša izmantošana | automatizētas kampaņas pret neielāpotiem serveriem | BSI gaidīta; apstiprināti veiksmīgi uzbrukumi plašā mērogā sākotnēji nebija zināmi |
| Jūsu ielāps | atjauninājums un pārstartēšana jūsu serveros | individuāli |
Pēdējā rinda ir vienīgā, ko jūs varat ietekmēt. Visu iepriekšējo nosaka citi.
Kāpēc pats ielāps palielina spiedienu
Drošības atjauninājums ievainojamību aizver, bet vienlaikus padara redzamu. Pirmkoda izmaiņas atvērtā koda projektos, piemēram, PHP, ir publiskas. Kas salīdzina atšķirības starp veco un jauno versiju, uzzina, kurā vietā bija kļūda. Tas nav pārmetums PHP projektam, bet atvērtas programmatūras norma un pamats tam, ka distributīvi var būvēt backport labojumus.
Operatoriem no tā izriet: ar katru dienu pēc ielāpa pieaug to skaits, kas zina, kā ievainojamība darbojas. Vienlaikus samazinās neielāpoto serveru skaits. Atlikušie tādējādi kļūst par pašsaprotamiem mērķiem. Kā PHP drošības atjauninājumus piegādā savas versiju uzturēšanas ietvaros, izskaidro raksts par PHP laidienu ciklu.
Ja jūsu serveris starp 17. oktobri un jūsu ielāpu bija sasniedzams, pēdu pārbaude ir nepieciešama. Saglabājiet žurnālus no 20. oktobra, pirms tie rotācijas dēļ tiek zaudēti.
Izmērīt savu laika logu
Jūsu personīgais laika logs sākas vēlākais ar ielāpu publicēšanu un beidzas ar pēdējā PHP procesa pārstartēšanu. Fiksējiet katram serverim:
- Zināšana: Kad kāds uzņēmumā uzzināja par ievainojamību?
- Pieejamība: Kad bija gatava jūsu distributīva vai hostinga sniedzēja pakotne?
- Instalēšana: Kad tā tika ieviesta?
- Pārstartēšana: Kad vairs nedarbojās veci PHP procesi?
Tieši pārstartēšanu bieži aizmirst. Instalēts atjauninājums darbojas tikai tad, kad veci procesi ir beigti. Kā to pārbaudīt, apraksta PHP-FPM un visu PHP procesu pārstartēšana. Vai joprojām darbojas procesi no laika pirms atjauninājuma, parāda skatiens uz startēšanas laikiem:
# Parādīt visu PHP procesu startēšanas laiku
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Ja startēšanas laiks ir pirms atjauninājuma instalēšanas, logs vēl ir atvērts.
Kāpēc jūsu logs ir atkarīgs no piegādes ceļa
Cik ātri varat ielāpot, nav atkarīgs tikai no jums, bet arī no tā, no kurienes nāk jūsu PHP. Distributīvi saskaņā ar ziņojumiem backport labojumus daļēji piegādāja jau 21. oktobrī. Kas PHP saņem no trešās puses repozitorija, tas ir atkarīgs no tā tempa. Kas izmanto konteinerus, tam jāpārbūvē un jāizvērš attēli, ar atjauninājumu darbojošos konteinerī vien nepietiek. Un koplietošanas hostingā laiku nosaka hostinga sniedzējs.
Ja zināt katra servera piegādes ceļu, zināt arī, kurā vietā jūsu logs paliek atvērts visilgāk. Tieši tur sagatavošanās atmaksājas visvairāk, piemēram, ar vienošanos ar hostinga sniedzēju vai pārbaudītu norisi jauniem konteineru attēliem.
Kā nākamreiz laika logu saīsināt
- Abonēt paziņojumus: Php.net un sava distributīva drošības paziņojumus saņemt tieši, nevis tikai caur presi.
- Noteikt atbildību: Katram serverim viena atbildīga persona ar aizvietotāju.
- Izmantot automātiku, kur tā der: Drošības atjauninājumus no distributīva var ieviest automātiski. Kas par to runā un kas pret, apraksta Automātiskie drošības atjauninājumi.
- Ieplānot pārstartēšanu: PHP pakalpojumu pārstartēšanai jābūt cieši procesā, nevis pēcapstrādē.
- Sagatavot avārijas ceļu: Paziņojuma lapa un lēmums par pagaidu atslēgšanu, ja atjauninājums nav iespējams uzreiz.
- Vest apliecinājumu: Dokumentēt instalēšanas un pārstartēšanas laikus, lai vēlāk savu logu varētu pierādīt.
Pastāvīgu procesu, kas šos punktus apvieno, apraksta raksts par ielāpu pārvaldības procesu.
Kā PHP SOS palīdz konkrēti?
- Ielāps un pārstartēšana: Mēs ieviešam atjauninājumu un nodrošinām, ka vairs nedarbojas veci PHP procesi.
- Laika loga apliecinājums: Mēs dokumentējam instalēšanu un pārstartēšanu katram serverim ar laiku.
- Pēdu pārbaude: Laikam, kurā jūsu serveris bija atvērts, mēs saglabājam žurnālus un pārbaudām novirzes.
- Process nākotnei: Mēs ar jums ierīkojam paziņošanas ceļus, atbildības un atjaunināšanas norises.
Vairāk sadaļā PHP ielāpu pakalpojums.
Secinājums
PHP2Shell gadījumā atbrīvojuma perioda nebija. Laika logs starp ielāpu un uzbrukumu kritisku ievainojamību gadījumā šodien bieži ir nulle vai pat negatīvs. Ko varat vadīt, ir jūsu pašu logs: tas beidzas ar pārstartēšanu, un ar sagatavošanos to var saīsināt no dienām uz stundām.
Biežāk uzdotie jautājumi
Cik laika pēc drošības atjauninājuma ir līdz uzbrukumiem?
Noteikta termiņa nav. PHP2Shell gadījumā saskaņā ar mediju ziņojumiem pirmais uzbrukuma mēģinājums tika novērots jau 17. oktobrī, tātad četras dienas pirms ielāpiem. Kritisku ievainojamību gadījumā plaši izplatītā programmatūrā jārēķinās, ka atbrīvojuma perioda praktiski nav.
Kas ir zero-day?
Ievainojamība, kurai uzbrūk, pirms ir pieejams atjauninājums. Ražotājam tā teikt bija nulle dienu laika to novērst. Pēc tam bieži runā par zināmu jeb N-Day ievainojamību, kurai jau ir ielāps.
Kāpēc uzbrukumi pēc ielāpa bieži kļūst biežāki?
Ar ielāpu kļūst publiski zināms, kurā vietā bija kļūda. Drošības pētnieki un uzbrucēji var izvērtēt izmaiņas. Vienlaikus daudzi serveri vēl dienas vai nedēļas paliek neielāpoti un tādējādi ir izdevīgi mērķi.
Kad mans serveris ir patiešām aizsargāts?
Kad atjauninājums ir instalēts un visi PHP procesi ir pārstartēti. Jauni faili vien nedarbojas, kamēr atmiņā darbojas veci procesi. Jūsu personīgā laika loga beigas tātad ir pārstartēšana, nevis lejupielāde.