# WAF alebo aktualizácia: prečo potrebujete obe

> WAF namiesto aktualizácie pri PHP2Shell? Čo WAF dokáže, kde sa končí a prečo zraniteľnosť uzavrie iba aktualizácia PHP spolu s reštartom.

Zdroj: https://phpsos.de/sk/blog/waf-oder-update/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** WAF namiesto aktualizácie pri PHP2Shell nefunguje. Web Application Firewall, teda filter pred webom, kontroluje požiadavky a môže blokovať známe vzory útokov. Zraniteľnosť samotná je však v interpreteri PHP a zmizne až s aktualizáciou a reštartom všetkých procesov PHP. WAF je zmysluplná dodatočná vrstva a most na niekoľko dní, nie riešenie.

## Prečo sa táto otázka kladie práve teraz tak často

Mnohí prevádzkovatelia si v týždni PHP2Shell prečítali zdanlivo dobrú správu: Cloudflare má podľa vlastných údajov od 21. 10. 2026, 03:02 UTC, aktívne ochranné pravidlá, aj pre zákazníkov v bezplatnom tarife. Kto je tak či tak za Cloudflare alebo inou WAF, sa pochopiteľne pýta, či aktualizácia potom ešte naliehavá.

Úprimná odpoveď je áno. Cloudflare sám upozorňuje na obmedzenie: Pravidlá založené len na údajoch požiadavky nestačia, preto služba navyše kontroluje odpoveď servera. Cloudflare navyše pozoroval zmenené vzory útokov. A ochrana funguje len pre prevádzku, ktorá skutočne prechádza cez Cloudflare. Podrobnosti o tomto poskytovateľovi opisuje článok [Ochranné pravidlá Cloudflare proti PHP2Shell](https://phpsos.de/sk/blog/cloudflare-waf-php2shell/). Tu ide o zásadné zvažovanie, nezávisle od poskytovateľa.

## Čo WAF vidí a čo mení aktualizácia

WAF stojí pred aplikáciou. Vidí každú požiadavku, porovnáva ju s pravidlami a prepustí ju, zablokuje alebo zaznamená. Nevie, ako požiadavku PHP interne spracuje. Obe zraniteľnosti PHP2Shell však vznikajú presne tam: CVE-2026-109618 pri stave nedostatku pamäte, kým sú údaje požiadavky iba čiastočne inicializované, CVE-2026-109619 vďaka internému stavu, ktorý po požiadavke zostane v tom istom workere.

Aktualizácia tento kód opravuje. Potom je príčina odstránená, bez ohľadu na to, ako požiadavka vyzerá. Kto chce pochopiť, na ktorom mieste v priebehu požiadavky sa to deje, nájde základy v článku [Životný cyklus požiadavky v PHP](https://phpsos.de/sk/php/request-lebenszyklus/).

## WAF namiesto aktualizácie: úprimné porovnanie

| Kritérium | Web Application Firewall | Aktualizácia PHP s reštartom |
|---|---|---|
| Čo sa opraví? | Nič, zachytávajú sa známe vzory | Príčina v interpreteri PHP |
| Ochrana pri nových variantoch útoku | Iba ak sa pravidlá včas upravia | Áno, zraniteľnosť už neexistuje |
| Je možné obísť? | Áno, napríklad cez priamu dostupnosť pôvodného servera | Nie, pokiaľ sú všetky procesy PHP reštartované |
| Rýchlosť | Často aktívna okamžite | Závisí od verzie, prístupu a servisného okna |
| Vedľajšie účinky | Falošné poplachy, narušené formuláre alebo nahrávanie | Zriedkavé, pri skokoch verzií sú potrebné testy kompatibility |
| Prínos pri ďalšej zraniteľnosti | Vysoký, ak je udržiavaná | Žiadny, každá zraniteľnosť potrebuje vlastnú aktualizáciu |
| Pomáha pri PHP 8.1 a starších? | Ako prechod | Iba cez backport alebo migráciu |

Tabuľka ukazuje, prečo obe opatrenia patria k sebe. WAF je rýchla a široká, ale nikdy nie úplná. Aktualizácia je úplná, ale iba pre konkrétnu zraniteľnosť a nie je vždy možná okamžite.

Jeden bod sa v praxi často prehliada: WAF mení správanie webu. Prísne pravidlá môžu blokovať legitímne objednávky, kontaktné formuláre alebo nahrávanie súborov, bez toho, aby si to niekto hneď všimol. Kto v krízovej situácii WAF sprísni, mal by preto najdôležitejšie postupy webu raz sám prejsť klikaním a protokoly prvých dní skontrolovať na zablokované, ale oprávnené požiadavky.

## Ako obe zmysluplne skombinovať

1. **Okamžite:** Preveriť, či WAF existuje a či sú aktívne zodpovedajúce pravidlá. Pri Cloudflare v platených tarifách podľa poskytovateľa nastaviť Managed Ruleset na Block.
2. **Okamžite:** Zabezpečiť, aby bol pôvodný server dostupný iba cez WAF, napríklad povolením vo firewalle len pre jej adresné rozsahy. Inak ochrana vyjde nazmar.
3. **V najbližšom servisnom okne:** Aktualizovať PHP na 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35, prípadne nainštalovať potvrdený backport distribúcie.
4. **Hneď potom:** Reštartovať všetkých workerov a procesy PHP a skontrolovať, že nebeží žiadny starý proces. Samotné nové súbory nestačia; viac v článku [Po aktualizácii: reštartovať PHP-FPM a všetkých workerov](https://phpsos.de/sk/php2shell/php-fpm-neustart/).
5. **Potom:** Pravidlá WAF ponechať, vyhodnocovať falošné poplachy a výnimky nastavovať cielene namiesto paušálneho vypínania pravidiel.

S vlastnou WAF na báze ModSecurity a OWASP Core Rule Set sa dá dosiahnuť podobné; základy opisuje článok [Nasadenie ModSecurity a OWASP Core Rule Set](https://phpsos.de/sk/blog/modsecurity-owasp-crs/). Osobitnou formou je filtrovanie požiadaviek na nahrávanie mimo skutočných ciest nahrávania, ktoré navrhli odborní autori. Je neoficiálne, môže pokaziť formuláre a do prevádzky patrí až po teste.

> **Dôležité:**
> Ani WAF, ani aktualizácia neodstránia škodlivý softvér, ktorý sa do systému dostal predtým. Po záplate skontrolujte, či sa od 17. 10. 2026 nevyskytli nápadnosti.

## Kedy WAF nepotrebujete a kedy nepotrebujete dodávateľa

WAF nie je povinná pre každý web. Malý firemný web u poskytovateľa hostingu, ktorý PHP včas záplatuje a potvrdzuje to, je často bez vlastnej WAF dostatočne chránený, ak sú CMS a pluginy aktuálne. Ani kto dokáže svoj server v krátkom čase aktualizovať sám, WAF ako most nepotrebuje.

Zmysel nadobúda pri obchodoch, portáloch a aplikáciách s mnohými formulármi, pri starých systémoch, ktoré sa nedajú hneď aktualizovať, a tam, kde sa má centrálne chrániť viac webov. Dodávateľa na to potrebujete len vtedy, ak nastavenie, testy a priebežnú údržbu interne nepokryjete.

## Ako konkrétne pomáha PHP SOS?

- Preverujeme, či vaša WAF skutočne stojí pred všetkými prístupmi a či je pôvodný server dostupný priamo.
- Pravidlá nastavujeme alebo upravujeme a formuláre, nahrávanie a rozhrania testujeme na vedľajšie účinky.
- Aktualizáciu PHP nainštalujeme, reštartujeme všetky procesy a stav zdokumentujeme.
- Tam, kde aktualizácia trvá, preklenujeme [WAF a virtuálnym záplatovaním](https://phpsos.de/sk/leistungen/waf-virtuelles-patching/) a pevným termínom pre skutočnú záplatu.

## Záver

Otázka „WAF alebo aktualizácia“ je položená nesprávne. Aktualizácia uzavrie zraniteľnosť, WAF získa čas a zachytí veľa iného. Kto sa spolieha len na WAF, spolieha sa na pravidlá, ktoré útočníci môžu obísť. Kto len záplatuje, stojí pri ďalšej zraniteľnosti opäť bez mosta.


## Časté otázky

**Stačí WAF ako ochrana proti PHP2Shell?**  
Nie. WAF kontroluje dátovú prevádzku a môže blokovať známe vzory útokov. Zraniteľnosť samotná je v interpreteri PHP a zostáva, kým sa PHP neaktualizuje a nereštartuje. Cloudflare výslovne zdôrazňuje, že jeho pravidlá aktualizáciu nenahrádzajú.

**Som za Cloudflare automaticky chránený?**  
Iba pre prevádzku, ktorá skutočne prechádza cez Cloudflare. Ak je pôvodný server (origin) dostupný priamo z internetu, ochrana sa obchádza. V platených tarifách by ste podľa Cloudflare mali preveriť, či je Managed Ruleset nastavený na Block.

**Oplatí sa WAF aj po aktualizácii?**  
Často áno. WAF môže zachytiť hromadné skeny, známe útoky na pluginy a zneužívanie prihlasovacích stránok a pri ďalšej zraniteľnosti získa čas. Potrebuje však údržbu a testy, inak falošné poplachy narúšajú prevádzku.

**Čo je virtuálne záplatovanie?**  
Rozumie sa tým dočasné odtienenie zraniteľnosti pravidlami pred aplikáciou namiesto zmeny kódu. Je to most do skutočnej aktualizácie, nie jej náhrada.

## Zdroje

- [Blog Cloudflare](https://blog.cloudflare.com/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [php.net: bezpečnostné hlásenia](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)