# WAF in virtualno popravljanje za PHP

> Virtualno popravljanje za PHP: WAF-pravila združimo z vmesnimi ukrepi po php.net, dokler posodobitev ni mogoča, in načrtujemo pravi popravek.

Vir: https://phpsos.de/sl/leistungen/waf-virtuelles-patching/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Virtualno popravljanje za PHP premosti čas do nameščene prave posodobitve. Zato združimo pravila Web Application Firewall z vmesnimi ukrepi, ki jih je php.net objavil za PHP2Shell, in takoj določimo pot do rednega popravka. Popolne zaščite to ne nudi, v prehodnem obdobju pa tveganje zmanjša.

## Kdaj je virtualno popravljanje za PHP smiselno

BSI pri PHP2Shell priporoča takojšnjo posodobitev in, če to ni mogoče, začasen odklop spletnih strežnikov z omrežja. Za številna podjetja nobeno od tega ni takoj izvedljivo: trgovina mora ostati dosegljiva, lasten razvoj pred posodobitvijo potrebuje preizkus ali pa strežnik teče s PHP 8.1 in starejšim, za kar ni več uradnih posodobitev.

V teh primerih je virtualno popravljanje most. Ne nadomešča odločitve, ali bi bilo delovanje brez povezave primernejše. To presojo opravite vi, mi zagotovimo tehnično oceno.

## Zakaj sam WAF ne zadošča

Cloudflare je poročal o opaženih poskusih napadov in uvedel zaščitna pravila, vendar opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. Razlog je v naravi ranljivosti. Pri CVE-2026-109618 lahko stanje Out of Memory prekine PHP, medtem ko so podatki zahteve le delno inicializirani. Pri CVE-2026-109619 lahko notranje stanje po sprostitvi pomnilnika ostane in ga uporabi poznejša zahteva v istem workerju. Takšne napake so odvisne od stanja strežnika, ne samo od vsebine posamezne zahteve.

Zato se opiramo na več plasti: pravila WAF pred strežnikom, vmesne ukrepe v samem PHP in okrepljeno opazovanje strežnika. Vsaka plast ujame del, nobena sama ne zadošča. Skupaj vam kupijo čas, da posodobitev namestite urejeno.

## Vmesni ukrepi po php.net

php.net navaja več nastavitev, ki tveganje zmanjšajo, izrecno brez popolne zaščite. Pomembno je, da aplikacije teh vrednosti ne morejo prepisati. Primer za pool PHP-FPM z nalaganji:

```ini
; Vmesni ukrepi PHP2Shell (brez popolne zaščite), nato znova zagnati vse workerje
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; samo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
```

Brez nalaganj php.net priporoča `post_max_size = 8M`. Ker se `memory_limit` odpravi, sodi zraven omejitev pomnilnika na ravni containerja ali cgroup, ne prek `RLIMIT_AS` ali `RLIMIT_DATA`. Nastavitev `session.upload_progress.enabled=0` sodi v php.ini, pool FPM ali konfiguracijo strežnika, ne v `ini_set()` ali `.user.ini`. Obenem je rešitev za opozorilo o [CVE-2026-115560](https://phpsos.de/sl/php2shell/cve-2026-115560/). Vse ukrepe v pregledu najdete na strani [Takojšnji ukrepi, če še ne morete popraviti](https://phpsos.de/sl/php2shell/sofortmassnahmen-ohne-patch/).

> **Pomembno:**
> Vmesni ukrepi delujejo šele po ponovnem zagonu vseh workerjev PHP. In ščitijo samo pred prihodnjimi napadi: ali je kdo vdrl že prej, ne povedo.

## Kdaj je delovanje brez povezave boljša izbira

Virtualno popravljanje ni v vsakem položaju pravi odgovor. Pri nekaterih konstelacijah svetujemo, da sledite BSI in spletni strežnik začasno odklopite z omrežja, dokler ni popravljen:

- strežnik teče z **Apacheem in mod_php**, kjer ekipa PHP tveganje ocenjuje najvišje in je bil exploit prikazan, še preden se sploh izvede koda aplikacije
- na strežniku ležijo **posebej varovani podatki**, na primer zdravstveni podatki, podatki strank pri svobodnih poklicih ali plačilni podatki
- **ni možnosti**, da bi se vmesni ukrepi trdno nastavili v konfiguraciji strežnika, na primer pri nekaterih paketih shared hostinga
- že obstajajo **znaki**, da je bil strežnik napaden

Začasno delovanje brez povezave ne pomeni, da je bila vaša spletna stran vdrta. Nekateri ponudniki so spletne strani iz previdnosti odklopili. Kratka, stvarna obvestilna stran za obiskovalce je potem običajno boljša rešitev kot nepojasnjen izpad.

## Kako konkretno pomaga PHP SOS?

1. **Preveriti stanje:** zabeležimo različice PHP, načine delovanja in obstoječe zaščitne plasti, kot so CDN, WAF ali reverse proxy. Pri mod_php opozorimo na povečano tveganje, ki ga tam vidi ekipa PHP.
2. **Zgraditi plasti:** vklopimo ali dopolnimo pravila WAF, vmesne ukrepe trdno nastavimo v konfiguraciji strežnika in pomnilnik omejimo prek containerja ali cgroup. Pri postavitvah z Nginxom se zgledujemo po strani [Zavarovanje Nginxa s PHP-FPM](https://phpsos.de/sl/server/nginx-php-fpm/).
3. **Ponovni zagon in preizkus:** vsi procesi PHP se znova zaženejo, nato preverimo nalaganja, obrazce, prijavo in blagajno.
4. **Opazovati:** v prehodnem obdobju okrepljeno spremljamo sesutja workerjev, konice pomnilnika in nenavadne procese.
5. **Načrtovati popravek:** določimo, kdaj in kako pride redna posodobitev, in jo izvedemo prek [storitve popravljanja PHP](https://phpsos.de/sl/leistungen/php-patch-service/).

## Kaj dobite, kaj potrebujemo in česa ne obljubljamo

Dobite dokumentacijo vseh nastavljenih pravil in nastavitev z obrazložitvijo, rezultate preizkusov ter časovni načrt in načrt ukrepov za pravi popravek. Od vas potrebujemo dostop do strežnika ali panela, dostop do CDN ali WAF, če obstaja, tehnično kontaktno osebo in podatke o funkcijah nalaganja vaših aplikacij.

Ne obljubljamo, da virtualno popravljanje napad prepreči. Tveganje zmanjša za omejen čas. Pri PHP 8.1 in starejšem to ni trajno stanje; tam sodi v načrt [selitev na podprto različico](https://phpsos.de/sl/leistungen/php-migration-legacy/).


## Pogosta vprašanja

**Kaj je virtualno popravljanje?**  
Virtualno popravljanje pomeni, da se znana ranljivost zaščiti pred aplikacijo, namesto da bi se spreminjala koda. To se večinoma zgodi prek Web Application Firewall ali s spremembami konfiguracije. Je premostitev, ne nadomestilo posodobitve.

**Ali WAF mojega ponudnika CDN proti PHP2Shell zadošča?**  
Sama praviloma ne. Cloudflare je uvedel zaščitna pravila, vendar sam opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. WAF je dodatna plast ob vmesnih ukrepih in popravku.

**Kako dolgo se smem zanašati na virtualno popravljanje?**  
Čim krajši čas. Namenjeno je premostitvi do redne posodobitve, na primer do prostega okna vzdrževanja ali preizkusa aplikacije. Pri PHP 8.1 in starejšem sodi zraven načrt selitve.

**Ali lahko vmesni ukrepi motijo mojo spletno stran?**  
Da, to je mogoče. Manjše omejitve nalaganja lahko preprečijo nalaganje velikih datotek, izklop session upload progress pa vpliva na prikaze napredka pri nalaganju. Najpomembnejše funkcije po vsaki spremembi preizkusimo.

## Viri

- [php.net: varnostna obvestila in vmesni ukrepi](https://www.php.net/)
- [BSI: nemški zvezni urad za informacijsko varnost](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)