# WAF või uuendus: miks vajate mõlemat

> WAF uuenduse asemel PHP2Shelli puhul? Mida veebirakenduse tulemüür suudab, kus see lõpeb ja miks ainult PHP uuendus koos taaskäivitusega turvaaugu sulgeb.

Allikas: https://phpsos.de/et/blog/waf-oder-update/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** WAF uuenduse asemel PHP2Shelli puhul ei toimi. Veebirakenduse tulemüür (Web Application Firewall), see tähendab filter veebisaidi ees, kontrollib päringuid ja võib tuntud ründemustreid blokeerida. Turvaauk ise asub aga PHP interpretaatoris ja kaob alles uuenduse ja kõigi PHP protsesside taaskäivitusega. WAF on mõistlik lisakiht ja sild mõneks päevaks, mitte lahendus.

## Miks seda küsimust just praegu nii sageli esitatakse

Paljud käitajad lugesid PHP2Shelli nädalal näiliselt head uudist: Cloudflare'il on enda andmetel alates 21.10.2026 kell 03:02 UTC kaitsereeglid aktiivsed, ka tasuta paketi klientidele. Kes niikuinii Cloudflare'i või mõne teise WAF-i taga seisab, küsib arusaadavalt, kas uuendus siis veel kiireloomuline on.

Aus vastus on jah. Cloudflare ise piirab: reeglitest üksnes päringuandmete põhjal ei piisa, seetõttu kontrollib teenus lisaks serveri vastust. Cloudflare on lisaks täheldanud muutunud ründemustreid. Ja kaitse toimib ainult liikluse puhul, mis tegelikult läbi Cloudflare'i liigub. Selle pakkuja üksikasju kirjeldab artikkel [Cloudflare'i kaitsereeglid PHP2Shelli vastu](https://phpsos.de/et/blog/cloudflare-waf-php2shell/). Siin on jutt põhimõttelisest kaalutlusest, pakkujast sõltumata.

## Mida WAF näeb ja mida uuendus muudab

WAF asub rakenduse ees. See näeb iga päringut, võrdleb seda reeglitega ning laseb läbi, blokeerib või logib. See ei tea, kuidas PHP päringut sisemiselt töötleb. Kaks PHP2Shelli turvaauku tekivad aga just seal: CVE-2026-109618 mälu otsasaamise (Out-of-Memory) olukorras, kui päringuandmed on ainult osaliselt initsialiseeritud, CVE-2026-109619 sisemise seisundi tõttu, mis jääb pärast päringut samasse tööprotsessi alles.

Uuendus parandab selle koodi. Seejärel on põhjus kõrvaldatud, ükskõik, milline päring välja näeb. Kes tahab mõista, millises kohas päringu kulus see toimub, leiab alused artiklist [Päringu elutsükkel PHP-s](https://phpsos.de/et/php/request-lebenszyklus/).

## WAF uuenduse asemel: aus võrdlus

| Kriteerium | Veebirakenduse tulemüür | PHP uuendus koos taaskäivitusega |
|---|---|---|
| Mida parandatakse? | Mitte midagi, tuntud mustrid püütakse kinni | Põhjus PHP interpretaatoris |
| Kaitse uute ründevariantide korral | Ainult kui reegleid õigeaegselt kohandatakse | Jah, turvaauku enam ei ole |
| Kas möödapääs on võimalik? | Jah, näiteks lähteserveri otsese ligipääsetavuse kaudu | Ei, kui kõik PHP protsessid on taaskäivitatud |
| Kiirus | Sageli kohe aktiivne | Sõltub versioonist, ligipääsust ja hooldusaknast |
| Kõrvalmõjud | Valehäired, häiritud vormid või üleslaadimised | Harva, versioonihüpete korral on vaja ühilduvustestide |
| Kasu järgmise turvaaugu korral | Kõrge, kui hooldatud | Puudub, iga turvaauk vajab oma uuendust |
| Kas aitab PHP 8.1 ja vanema puhul? | Üleminekuna | Ainult tagasiportimise (backport) või migratsiooni kaudu |

Tabel näitab, miks mõlemad meetmed kuuluvad kokku. WAF on kiire ja lai, kuid mitte kunagi täielik. Uuendus on täielik, kuid ainult konkreetse turvaaugu jaoks ja mitte alati kohe võimalik.

Üht punkti jäetakse praktikas sageli tähelepanuta: WAF muudab veebisaidi käitumist. Ranged reeglid võivad blokeerida õigustatud tellimusi, kontaktivorme või failide üleslaadimisi, ilma et keegi seda kohe märkaks. Kes lülitab WAF-i kriisis teravaks, peaks seetõttu veebisaidi olulisemad kulgemised ühe korra ise läbi klõpsama ja esimeste päevade protokolle kontrollima blokeeritud, kuid õigustatud päringute suhtes.

## Nii kombineerite mõlemat mõistlikult

1. **Kohe:** Kontrollida, kas WAF on olemas ja kas sobivad reeglid on aktiivsed. Cloudflare'i tasuliste pakettide puhul seada pakkuja andmetel Managed Ruleset režiimile Block.
2. **Kohe:** Tagada, et lähteserver on ligipääsetav ainult WAF-i kaudu, näiteks tulemüüri vabastusega ainult nende aadressivahemikele. Muidu jookseb kaitse tühjalt.
3. **Järgmise hooldusakna jooksul:** Uuendada PHP versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35 või paigaldada distributsiooni kinnitatud tagasiportimine.
4. **Vahetult pärast:** Taaskäivitada kõik PHP tööprotsessid ja protsessid ning kontrollida, et ükski vana protsess enam ei tööta. Uutest failidest üksi ei piisa; lähemalt artiklis [Pärast uuendust: PHP-FPM-i ja kõigi tööprotsesside taaskäivitamine](https://phpsos.de/et/php2shell/php-fpm-neustart/).
5. **Seejärel:** Hoida WAF-i reeglid alles, hinnata valehäireid ja seada erandid sihipäraselt, mitte lülitada reegleid üldiselt välja.

Oma WAF-iga ModSecurity ja OWASP Core Rule Set'i baasil saab saavutada sarnast; alused kirjeldab artikkel [ModSecurity ja OWASP Core Rule Set'i kasutamine](https://phpsos.de/et/blog/modsecurity-owasp-crs/). Erivorm on eriala autorite pakutud üleslaadimispäringute filtreerimine väljaspool tegelikke üleslaadimisteid. See on mitteametlik, võib vorme rikkuda ja kuulub tegevusse alles pärast testimist.

> **Oluline:**
> Ei WAF ega uuendus eemalda pahavara, mis on varem sisse toodud. Kontrollige pärast paika, kas alates 17.10.2026 on esinenud kõrvalekaldeid.

## Millal te WAF-i ei vaja ja millal teenusepakkujat

WAF ei ole iga veebisaidi jaoks kohustuslik. Väike ettevõtte veebisait veebimajutaja juures, kes paigab PHP õigeaegselt ja seda kinnitab, on ilma oma WAF-ita sageli piisavalt kaitstud, kui CMS ja pistikprogrammid on ajakohased. Ka kes saab oma serveri lühikese ajaga ise uuendada, ei vaja WAF-i sillana.

Mõistlikuks muutub see poodide, portaalide ja paljude vormidega rakenduste puhul, vanasüsteemide puhul, mida ei saa kohe uuendada, ja seal, kus mitut veebisaiti tuleb tsentraalselt kaitsta. Teenusepakkujat vajate selleks ainult siis, kui seadistus, testid ja jooksev hooldus ei ole ettevõttesiseselt kaetud.

## Kuidas PHP SOS konkreetselt aitab?

- Kontrollime, kas teie WAF asub tegelikult kõigi ligipääsude ees ja kas lähteserver on otse ligipääsetav.
- Seadistame reeglid või kohandame neid ning testime vorme, üleslaadimisi ja liideseid kõrvalmõjude suhtes.
- Paigaldame PHP uuenduse, taaskäivitame kõik protsessid ja dokumenteerime seisu.
- Kus uuendus võtab aega, ületame selle [WAF-i ja virtuaalse paikamisega](https://phpsos.de/et/leistungen/waf-virtuelles-patching/) ning kindla tähtajaga tõelisele paigale.

## Kokkuvõte

Küsimus „WAF või uuendus“ on valesti püstitatud. Uuendus sulgeb turvaauku, WAF annab aega ja püüab palju muud kinni. Kes toetub ainult WAF-ile, loodab reeglitele, mida ründajad võivad mööda minna. Kes ainult paikab, seisab järgmise turvaaugu korral taas ilma sillata.


## Korduma kippuvad küsimused

**Kas WAF piisab kaitseks PHP2Shelli vastu?**  
Ei. WAF kontrollib andmeliiklust ja võib blokeerida tuntud ründemustreid. Turvaauk ise asub PHP interpretaatoris ja jääb alles, kuni PHP on uuendatud ja taaskäivitatud. Cloudflare rõhutab sõnaselgelt, et tema reeglid ei asenda uuendust.

**Kas olen Cloudflare'i taga automaatselt kaitstud?**  
Ainult liikluse osas, mis tegelikult läbi Cloudflare'i liigub. Kui lähteserver on internetist otse ligipääsetav, kaitsest mööda minnakse. Tasuliste paketite puhul peaksite Cloudflare'i andmetel kontrollima, et Managed Ruleset on režiimil Block.

**Kas WAF tasub end pärast uuendust veel ära?**  
Sageli jah. WAF võib tõrjuda massilisi skannimisi, tuntud rünnakuid pistikprogrammide vastu ja sisselogimislehtede kuritarvitamist ning annab järgmise turvaaugu korral aega. See vajab aga hooldust ja teste, muidu segavad valehäired tegevust.

**Mis on virtuaalne paikamine?**  
Sellega mõeldakse turvaaugu ajutist varjamist reeglitega rakenduse ees, koodi muutmata. See on sild tõelise uuenduseni, mitte asendus.

## Allikad

- [Cloudflare'i blogi](https://blog.cloudflare.com/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [php.net: turvateated](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)