# Laiko langas tarp pataisos ir atakos

> Laiko langas tarp pataisos ir atakos paaiškintas: PHP2Shell fazės, kaip išmatuoti savo langą ir kokiais žingsniais jį sutrumpinti.

Šaltinis: https://phpsos.de/lt/blog/zeitfenster-patch-angriff/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** Su PHP2Shell laiko langas tarp pataisos ir atakos buvo neigiamas: pasak žiniasklaidos pranešimų, pirmas atakos bandymas įvyko jau 2026 m. spalio 17 d., keturiomis dienomis prieš atnaujinimus. Operatoriams todėl svarbus ne klausimas „Kiek laiko lieka?“, o „Kiek laiko mano serveris atviras?“. Šis asmeninis langas baigiasi tik tada, kai atnaujinimas įdiegtas ir visi PHP procesai paleisti iš naujo.

## Pradžia: atakos prieš pataisą

Ilgai galiojo patogi prielaida: tarp saugumo atnaujinimo ir pirmųjų atakų praeina kelios dienos, pakankamai laiko kitam aptarnavimo langui. PHP2Shell šią prielaidą paneigė. Pasak žiniasklaidos pranešimų, besiremiančių Amazon, pirmas atakos bandymas buvo pastebėtas jau spalio 17 d. Apie ankstyvas atakas pranešė ir Cloudflare. Pataisos pasirodė spalio 21 d. 14:00 UTC.

Šiame straipsnyje paaiškinama, kaip atsiranda tokie laiko langai ir kaip sutrumpinti savąjį. Tikslią datų seką rasite [PHP2Shell laiko juostoje](https://phpsos.de/lt/ratgeber/php2shell-chronologie/).

## Laiko langas tarp pataisos ir atakos fazėmis

Aplink saugumo spragą galima išskirti kelias fazes. Su PHP2Shell jos atrodė taip:

| Fazė | Bendrai | Su PHP2Shell |
|---|---|---|
| Prieš paviešinimą | spraga žinoma tik atradėjams ir gamintojui | taisymo kūrimas pagal embargą |
| Pirmos atakos be pataisos | užpuolikai spragą naudoja, kol atnaujinimo dar nėra | pasak žiniasklaidos pranešimų, pirmas bandymas spalio 17 d. |
| Išankstinis pranešimas | gamintojas paskelbia atnaujinimą | spalio 20 d., php.net paskelbia leidimą |
| Pataisa prieinama | pasirodo atnaujinimas ir saugumo pranešimas | spalio 21 d., 14:00 UTC |
| Pataisos analizė | tyrėjai ir užpuolikai analizuoja pakeitimus | watchTowr, pasak jų pačių, CVE-2026-109618 atkūrė |
| Plati ataka | automatizuotos kampanijos prieš nepataisytus serverius | BSI tikėtasi; patvirtintų sėkmingų plataus masto atakų iš pradžių nežinota |
| Jūsų pataisa | atnaujinimas ir paleidimas iš naujo jūsų serveriuose | individualiai |

Paskutinė eilutė yra vienintelė, kurią galite paveikti. Viską, kas prieš tai, lemia kiti.

## Kodėl pati pataisa padidina spaudimą

Saugumo atnaujinimas spragą uždaro, bet kartu ją padaro matomą. Šaltinio kodo pakeitimai atvirojo kodo projektuose, tokiuose kaip PHP, yra vieši. Kas palygina senos ir naujos versijos skirtumus, sužino, kurioje vietoje buvo klaida. Tai ne priekaištas PHP projektui, o normalus atvirosios programinės įrangos atvejis ir pagrindas, kad distribucijos gali kurti atgalinius perkėlimus (backport).

Operatoriams iš to išplaukia: kiekviena diena po pataisos didina tų, kurie žino, kaip spraga veikia, skaičių. Kartu mažėja nepataisytų serverių skaičius. Likusieji tampa akivaizdžiais taikiniais. Kaip PHP saugumo atnaujinimus pateikia versijų priežiūros metu, paaiškina straipsnis apie [PHP leidimų ciklą](https://phpsos.de/lt/php/release-zyklus/).

> **Veikti nedelsiant:**
> Jei jūsų serveris buvo pasiekiamas tarp spalio 17 d. ir jūsų pataisos, pėdsakų patikra yra būtina. Išsaugokite žurnalus nuo spalio 20 d., kol jų neprarado dėl rotacijos.

## Savo laiko lango matavimas

Jūsų asmeninis laiko langas prasideda ne vėliau kaip pataisų paskelbimo momentu ir baigiasi paskutinio PHP proceso paleidimu iš naujo. Kiekvienam serveriui užfiksuokite:

- **Žinojimas:** kada kas nors įmonėje sužinojo apie spragą?
- **Prieinamumas:** kada jūsų distribucijos ar talpintojo paketas buvo paruoštas?
- **Įdiegimas:** kada jis įdiegtas?
- **Paleidimas iš naujo:** kada nebeveikė seni PHP procesai?

Būtent paleidimas iš naujo dažnai pamirštamas. Įdiegtas atnaujinimas pradeda veikti tik tada, kai seni procesai užbaigti. Kaip tai patikrinti, aprašo [PHP-FPM ir visų PHP procesų paleidimas iš naujo](https://phpsos.de/lt/php2shell/php-fpm-neustart/). Ar dar veikia procesai iš laikų prieš atnaujinimą, parodo žvilgsnis į paleidimo laikus:

```bash
# Rodyti visų PHP procesų paleidimo laiką
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
```

Jei paleidimo laikas yra prieš atnaujinimo įdiegimą, langas dar atviras.

### Kodėl jūsų langas priklauso nuo gavimo kelio

Kaip greitai galite taisyti, priklauso ne tik nuo jūsų, bet ir nuo to, iš kur ateina jūsų PHP. Distribucijos, pasak pranešimų, atgalinius perkėlimus dalinai pateikė dar spalio 21 d. Kas PHP gauna iš trečiosios šalies saugyklos, priklauso nuo jos tempo. Kas naudoja konteinerius, turi iš naujo sukurti ir paskleisti atvaizdus, vien atnaujinimo veikiančiame konteineryje nepakanka. O bendrinamame talpinime laiką nustato talpintojas.

Kas žino kiekvieno serverio gavimo kelią, žino ir tai, kurioje vietoje jo langas ilgiausiai lieka atviras. Būtent ten pasirengimas labiausiai atsiperka, pavyzdžiui, susitarimu su talpintoju arba išbandyta eiga naujiems konteinerių atvaizdams.

## Kaip kitą kartą sutrumpinti laiko langą

1. **Užsiprenumeruoti pranešimus:** php.net ir savo distribucijos saugumo pranešimus gauti tiesiogiai, o ne tik per spaudą.
2. **Nustatyti atsakomybę:** kiekvienam serveriui atsakingas asmuo su pavaduotoju.
3. **Naudoti automatiką, kur tinka:** saugumo atnaujinimai iš distribucijos gali būti diegiami automatiškai. Kas už tai kalba ir kas prieš, aprašo [Automatiniai saugumo atnaujinimai](https://phpsos.de/lt/blog/automatische-sicherheitsupdates/).
4. **Numatyti paleidimą iš naujo:** PHP tarnybų paleidimas iš naujo turi būti nuolatinė eigos dalis, o ne paskesnio darbo dalis.
5. **Paruošti avarinį kelią:** avarinis puslapis ir sprendimas dėl laikino išjungimo, jei atnaujinimas iš karto neįmanomas.
6. **Vesti įrodymus:** dokumentuoti įdiegimo ir paleidimo iš naujo laiką, kad savo langą vėliau galėtumėte įrodyti.

Nuolatinis procesas, kuris šiuos punktus sujungia, aprašytas straipsnyje apie [pataisų valdymo procesą](https://phpsos.de/lt/blog/patch-management-prozess/).

## Kaip PHP SOS padeda konkrečiai?

- **Pataisa ir paleidimas iš naujo:** Įdiegiame atnaujinimą ir užtikriname, kad nebeveiktų seni PHP procesai.
- **Laiko lango įrodymas:** Dokumentuojame kiekvieno serverio įdiegimą ir paleidimą iš naujo su laiku.
- **Pėdsakų patikra:** Laikotarpiui, kai jūsų serveris buvo atviras, saugome žurnalus ir tikriname dėl neįprastumų.
- **Procesas ateičiai:** Su jumis nustatome pranešimų kelius, atsakomybes ir atnaujinimo eigas.

Daugiau skaitykite skyrelyje [PHP pataisų paslauga](https://phpsos.de/lt/leistungen/php-patch-service/).

## Išvada

Su PHP2Shell atidėjimo laikotarpio nebuvo. Laiko langas tarp pataisos ir atakos kritinių spragų atveju šiandien dažnai yra nulis arba net neigiamas. Ką galite valdyti, yra savo langas: jis baigiasi paleidimu iš naujo ir pasirengimu gali būti sutrumpintas nuo dienų iki valandų.


## Dažni klausimai

**Kiek laiko po saugumo atnaujinimo lieka iki atakų?**  
Fiksuoto termino nėra. Su PHP2Shell, pasak žiniasklaidos pranešimų, pirmas atakos bandymas buvo pastebėtas jau spalio 17 d., t. y. keturiomis dienomis prieš pataisas. Dėl kritinių spragų paplitusioje programinėje įrangoje reikėtų manyti, kad atidėjimo laikotarpio praktiškai nėra.

**Kas yra Zero-Day?**  
Spraga, kuri užpuolama prieš atsirandant atnaujinimui. Gamintojas tarsi turėjo nulį dienų ją ištaisyti. Vėliau dažnai kalbama apie žinomą arba N-Day spragą, kuriai jau yra pataisa.

**Kodėl po pataisos atakų dažnai padaugėja?**  
Su pataisa viešai paaiškėja, kurioje vietoje buvo klaida. Saugumo tyrėjai ir užpuolikai gali analizuoti pakeitimus. Kartu daug serverių dar dienas ar savaites lieka nepataisyti ir todėl yra vertingi taikiniai.

**Kada mano serveris iš tikrųjų apsaugotas?**  
Kai atnaujinimas įdiegtas ir visi PHP procesai paleisti iš naujo. Vien nauji failai neveikia, kol atmintyje veikia seni procesai. Jūsų asmeninio laiko lango pabaiga todėl yra paleidimas iš naujo, o ne atsisiuntimas.

## Šaltiniai

- [php.net: saugumo pranešimai](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)