Lyhyesti: WAF päivityksen sijaan ei toimi PHP2Shellin kohdalla. Web Application Firewall eli verkkosivuston edessä toimiva suodatin tarkastaa pyyntöjä ja voi estää tunnettuja hyökkäyskuvioita. Aukko itse on kuitenkin PHP-tulkissa ja häviää vasta päivityksen ja kaikkien PHP-prosessien uudelleenkäynnistyksen myötä. WAF on järkevä lisäkerros ja silta muutamaksi päiväksi, ei ratkaisu.
Miksi kysymystä esitetään juuri nyt niin usein
Monet ylläpitäjät lukivat PHP2Shell-viikolla näennäisen hyvän uutisen: Cloudflarella on omien tietojensa mukaan 21.10.2026 kello 03.02 UTC alkaen aktiiviset suojasäännöt, myös ilmaisen tariffin asiakkaille. Joka on joka tapauksessa Cloudflaren tai muun WAF:n takana, kysyy ymmärrettävästi, onko päivitys silloin vielä kiireellinen.
Rehellinen vastaus on kyllä. Cloudflare itse rajaa: pelkät pyyntötietoihin perustuvat säännöt eivät riitä, siksi palvelu tarkastaa lisäksi palvelimen vastauksen. Cloudflare on myös havainnut muuttuneita hyökkäyskuvioita. Ja suoja tehoaa vain liikenteeseen, joka todella kulkee Cloudflaren kautta. Tämän palveluntarjoajan yksityiskohdat kuvaa sivu Cloudflaren suojasäännöt PHP2Shelliä vastaan. Tässä on kyse periaatteellisesta punninnasta palveluntarjoajasta riippumatta.
Mitä WAF näkee ja mitä päivitys muuttaa
WAF toimii sovelluksen edessä. Se näkee jokaisen pyynnön, vertaa sitä sääntöihin ja päästää sen läpi, estää sen tai kirjaa sen. Se ei tiedä, miten PHP käsittelee pyyntöä sisäisesti. PHP2Shellin molemmat aukot syntyvät kuitenkin juuri siellä: CVE-2026-109618 muistin loppumistilanteessa (out-of-memory), kun pyyntötiedot on alustettu vain osittain, CVE-2026-109619 sisäisen tilan kautta, joka säilyy pyynnön jälkeen samassa työprosessissa.
Päivitys korjaa tämän koodin. Sen jälkeen syy on poistettu riippumatta siitä, miltä pyyntö näyttää. Joka haluaa ymmärtää, missä kohtaa pyynnön kulkua tämä tapahtuu, löytää perusteet sivulta PHP:n pyynnön elinkaari.
WAF päivityksen sijaan: rehellinen vertailu
| Kriteeri | Web Application Firewall | PHP-päivitys uudelleenkäynnistyksellä |
|---|---|---|
| Mitä korjataan? | Ei mitään, tunnettuja kuvioita torjutaan | Syy PHP-tulkissa |
| Suoja uusilta hyökkäysvariaateilta | Vain jos säännöt mukautetaan ajoissa | Kyllä, aukkoa ei enää ole |
| Voiko ohittaa? | Kyllä, esimerkiksi alkuperäisen palvelimen suoran tavoitettavuuden kautta | Ei, kunhan kaikki PHP-prosessit on käynnistetty uudelleen |
| Nopeus | Usein heti aktiivinen | Riippuu versiosta, pääsystä ja huoltoikkunasta |
| Sivuvaikutukset | Väärät hälytykset, häiriintyneet lomakkeet tai lataukset | Harvoin, versiohypyissä tarvitaan yhteensopivuustestejä |
| Hyöty seuraavan aukon kohdalla | Korkea, jos ylläpidetty | Ei lainkaan, jokainen aukko tarvitsee oman päivityksensä |
| Auttaako PHP 8.1:ssä ja vanhemmissa? | Siirtymävaiheessa | Vain backportin tai siirron kautta |
Taulukko osoittaa, miksi molemmat toimenpiteet kuuluvat yhteen. WAF on nopea ja laaja, mutta ei koskaan täydellinen. Päivitys on täydellinen, mutta vain tiettyä aukkoa varten eikä aina heti mahdollinen.
Yksi kohta jää käytännössä usein huomaamatta: WAF muuttaa verkkosivuston käyttäytymistä. Tiukat säännöt voivat estää oikeutettuja tilauksia, yhteydenottolomakkeita tai tiedostolatauksia, ilman että kukaan huomaa sitä heti. Joka ottaa WAF:n käyttöön kriisissä, kannattaa siksi käydä itse läpi verkkosivuston tärkeimmät kulut ja tarkistaa ensimmäisten päivien lokeista estetyt mutta oikeutetut pyynnöt.
Näin yhdistätte molemmat järkevästi
- Heti: Tarkistakaa, onko WAF olemassa ja ovatko oikeat säännöt aktiivisina. Cloudflaren maksullisissa tariffeissa asettakaa palveluntarjoajan mukaan Managed Ruleset tilaan Block.
- Heti: Varmistakaa, että alkuperäinen palvelin on tavoitettavissa vain WAF:n kautta, esimerkiksi palomuurin sallinnalla vain niiden osoitealueille. Muuten suoja jää tyhjäksi.
- Seuraavan huoltoikkunan aikana: Päivittäkää PHP versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai asentakaa jakelun vahvistettu backport.
- Heti sen jälkeen: Käynnistäkää kaikki PHP-työprosessit uudelleen ja tarkistakaa, ettei vanhoja prosesseja enää ole käynnissä. Uudet tiedostot yksin eivät riitä; lisää sivulla Päivityksen jälkeen: PHP-FPM ja kaikki työprosessit uudelleen.
- Sen jälkeen: Säilyttäkää WAF-säännöt, arvioikaa väärät hälytykset ja asettakaa poikkeukset kohdennetusti sääntöjen yleisen poiskytkemisen sijaan.
Samankaltaiseen päästään oman ModSecurityyn ja OWASP Core Rule Setiin perustuvan WAF:n avulla; perusteet kuvaa sivu ModSecurityn ja OWASP Core Rule Setin käyttö. Erikoismuoto on alan kirjoittajien ehdottama upload-pyyntöjen suodatus varsinaisten latauspolkujen ulkopuolella. Se on epävirallinen, voi rikkoa lomakkeita ja kuuluu käyttöön vasta testin jälkeen.
Ei WAF eikä päivitys poista haittaohjelmaa, joka on tuotu sisään aiemmin. Tarkistakaa korjauksen jälkeen, onko 17.10.2026 alkaen ilmennyt poikkeamia.
Milloin ette tarvitse WAF:ia ja milloin palveluntarjoajaa
WAF ei ole pakollinen jokaiselle verkkosivustolle. Pieni yrityksen verkkosivusto hosting-yrityksellä, joka päivittää PHP:n ajoissa ja vahvistaa sen, on ilman omaa WAF:ia usein riittävästi suojattu, kun CMS ja lisäosat ovat ajan tasalla. Myös joka pystyy päivittämään palvelimensa itse lyhyessä ajassa, ei tarvitse WAF:ia siltana.
Järkeväksi se muuttuu verkkokaupoissa, portaaleissa ja sovelluksissa, joissa on paljon lomakkeita, vanhoissa järjestelmissä, joita ei voi päivittää heti, ja siellä, missä useita verkkosivustoja halutaan suojata keskitetysti. Palveluntarjoajaa tarvitsette siihen vain, jos käyttöönottoa, testejä ja jatkuvaa ylläpitoa ei hoideta sisäisesti.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme, onko WAF todella kaikkien käyttöpolkujen edessä ja onko alkuperäinen palvelin tavoitettavissa suoraan.
- Otamme käyttöön säännöt tai mukautamme niitä ja testaamme lomakkeet, lataukset ja rajapinnat sivuvaikutusten varalta.
- Asennamme PHP-päivityksen, käynnistämme kaikki prosessit uudelleen ja dokumentoimme tilan.
- Missä päivitys kestää, ylitämme ajan WAF:lla ja virtuaalisella paikkauksella sekä kiinteällä määräpäivällä varsinaiselle korjaukselle.
Yhteenveto
Kysymys ”WAF vai päivitys” on asetettu väärin. Päivitys sulkee aukon, WAF antaa aikaa ja torjuu paljon muuta. Joka luottaa vain WAF:iin, luottaa sääntöihin, jotka hyökkääjät voivat kiertää. Joka vain päivittää, jää seuraavan aukon kohdalla taas ilman siltaa.
Usein kysytyt kysymykset
Riittääkö WAF suojaksi PHP2Shelliä vastaan?
Ei. WAF tarkastaa tietoliikennettä ja voi estää tunnettuja hyökkäyskuvioita. Aukko itse on PHP-tulkissa ja säilyy, kunnes PHP on päivitetty ja käynnistetty uudelleen. Cloudflare korostaa nimenomaisesti, etteivät sen säännöt korvaa päivitystä.
Olenko Cloudflaren takana automaattisesti suojattu?
Vain sen liikenteen osalta, joka todella kulkee Cloudflaren kautta. Jos alkuperäinen palvelin on tavoitettavissa suoraan internetistä, suoja ohitetaan. Maksullisissa tariffeissa teidän pitäisi Cloudflaren mukaan tarkistaa, että Managed Ruleset on tilassa Block.
Kannattaako WAF vielä päivityksen jälkeen?
Usein kyllä. WAF voi torjua massaskannauksia, tunnettuja hyökkäyksiä lisäosia vastaan ja kirjautumissivujen väärinkäyttöä, ja se antaa aikaa seuraavan aukon kohdalla. Se tarvitsee kuitenkin ylläpitoa ja testejä, muuten vääriä hälytyksiä häiritsevät toimintaa.
Mitä on virtuaalinen paikkaus?
Sillä tarkoitetaan haavoittuvuuden tilapäistä suojaamista säännöillä sovelluksen edessä koodin muuttamisen sijaan. Se on silta varsinaiseen päivitykseen, ei korvike.