# Zaščita Apacheja z mod_php

> Apache mod_php po PHP2Shell: prepoznajte način delovanja, popravite modul PHP, popolnoma znova zaženite Apache in čisto pripravite prehod na PHP-FPM.

Vir: https://phpsos.de/sl/server/apache-mod-php/  
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:** Pri Apachu z mod_php PHP teče neposredno v spletnem strežniku. Ekipa PHP tveganje zaradi PHP2Shell prav v tem načinu delovanja ocenjuje kot najvišje, ker je bil exploit prikazan, še preden se sploh izvede koda aplikacije. Popravite takoj, Apache popolnoma znova zaženite in nato načrtujte prehod na PHP-FPM.

## Kaj je mod_php in zakaj je zdaj pomemben

Pri mod_php Apache naloži PHP kot modul v vsak lasten delovni proces. Vsaka zahteva za datoteko PHP se izvede neposredno v tem procesu. To je bil dolgo standard in ga je preprosto nastaviti. Pomeni pa tudi: vse spletne strani na strežniku tečejo z istim uporabnikom, PHP pa si proces deli s spletnim strežnikom.

PHP2Shell obsega ranljivosti CVE-2026-109618 in CVE-2026-109619, obe s CVSS v4.0 9,2. Pri drugi lahko notranje stanje zahteve po sprostitvi pomnilnika ostane in ga uporabi poznejša zahteva v istem procesu. Za mod_php je ekipa PHP ugotovila najvišje tveganje. Ozadje in umestitev so na strani [Zakaj ima mod_php najvišje tveganje](https://phpsos.de/sl/php2shell/mod-php-risiko/).

## Prepoznajte Apache mod_php in preverite različico

Najprej preverite, ali vaš Apache sploh uporablja mod_php. Spodnji ukazi samo berejo. Imena ukazov in paketov se razlikujejo glede na distribucijo in so primeri.

```bash
# Debian/Ubuntu: naloženi moduli
apache2ctl -M 2>/dev/null | grep -i php

# Družina RHEL
httpd -M 2>/dev/null | grep -i php

# Kateri MPM je aktiven? mod_php zahteva prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Stanje paketa modula (primeri)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
```

Če se pojavi modul, kot je `php_module`, teče mod_php. Prikazana različica PHP sama ni dokaz popravka, ker distribucije popravke pogosto namestijo kot backport. Odpravljene različice projekta PHP so 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Pri paketih distribucij šteje dnevnik sprememb s številkami CVE.

## Popravite in Apache popolnoma znova zaženite

Posodobitev namestite prek upravitelja paketov. Ker je PHP v procesu Apache, je treba nato znova zagnati celotno storitev. Ponovno nalaganje konfiguracije tu ni varna pot.

```bash
# Debian/Ubuntu
systemctl restart apache2

# Družina RHEL
systemctl restart httpd

# Kontrola: čas zagona vseh procesov Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Vsi procesi Apache morajo kazati čas zagona po posodobitvi. Če na istem strežniku dodatno teče PHP-FPM ali php-cgi, znova zaženite tudi te storitve.

> **Ukrepajte takoj:**
> Če za vašo različico PHP popravka še ni, BSI priporoča, da spletni strežnik začasno odklopite z omrežja. Pri mod_php je to še posebej pomembno, ker lahko napad zaleže pred kodo aplikacije.

## Vmesni ukrepi v konfiguraciji Apache

php.net navaja vmesne ukrepe, ki tveganje zmanjšajo, a ne nudijo popolne zaščite. Pri mod_php vrednosti nastavite s `php_admin_value` oziroma `php_admin_flag` v konfiguraciji Apache, da jih `.htaccess` in aplikacije ne morejo prepisati.

```apache
# Primer: v konfiguraciji VirtualHost ali strežniško
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>
```

S funkcijo nalaganja datotek php.net navaja `post_max_size = 32M`, `upload_max_filesize` pa pod tem. Pri PHP 8.5 se doda `fatal_error_backtraces=0`. Napotek o `memory_limit=-1` uveljavite samo skupaj z omejitvijo pomnilnika za storitev prek cgroups, na primer z `MemoryMax` v dopolnilu systemd, ne prek `RLIMIT_AS` ali `RLIMIT_DATA`. Nato Apache popolnoma znova zaženite. Vsi ukrepi na pregled: [Takojšnji ukrepi brez popravka](https://phpsos.de/sl/php2shell/sofortmassnahmen-ohne-patch/).

## Pot stran od mod_php

Po akutnem popravku se splača preiti na PHP-FPM. Pri tem PHP teče v lastnih procesih, ločeno od spletnega strežnika. Vsaka spletna stran lahko dobi lasten pool z lastnim uporabnikom, meje je mogoče nastaviti za vsak pool, ponovni zagoni pa zadevajo samo PHP. Apache PHP-FPM poveže prek `mod_proxy_fcgi` in lahko namesto prefork uporablja modernejši MPM, kot je event.

Prehod načrtujte v testnem okolju: ustvarite poole za vsako spletno stran, prilagodite pravice za datoteke novim uporabnikom, vnose `.htaccess` s `php_value` prenesite v nastavitve poola, izvedite obremenitvene teste. Kako je videti čista zgradba, kaže stran [Zaščita Nginxa s PHP-FPM](https://phpsos.de/sl/server/nginx-php-fpm/); načela veljajo tudi za Apache s PHP-FPM.

Ne glede na način delovanja velja: popravek ne odstrani že vnesene škodljive programske opreme. Dnevnike hranite od 20. 10. 2026 naprej in strežnik preverite glede sledi.

Pri iskanju sledi na strežnikih z mod_php je smiseln pogled na skupnega uporabnika. Ker vse spletne strani tečejo pod uporabnikom Apache, na primer `www-data` ali `apache`, lahko napadalec, ki je prevzel eno spletno stran, praviloma bere in spreminja tudi datoteke drugih. Zato ne preverjajte samo spletne strani, ki se vam zdi sumljiva, temveč vse imenike Document Root na strežniku. Bodite posebej pozorni na datoteke PHP z mladim datumom spremembe v imenikih za nalaganje in predpomnilnik, na programsko kodo, ki pripada uporabniku Apache, in na neznane vnose v crontab tega uporabnika. Če kaj najdete, najprej zavarujte stanje in ne brišite prenagljeno, da ostane vzrok pozneje sledljiv.

## Kako PHP SOS konkretno pomaga?

- Preverimo način delovanja, MPM in stanje paketov ter ocenimo, ali je vaš strežnik res popravljen.
- Prek [storitve popravljanja PHP](https://phpsos.de/sl/leistungen/php-patch-service/) namestimo posodobitev, Apache popolnoma znova zaženemo in dokumentiramo dokaz.
- Do popravka vmesne ukrepe nastavimo tako, da jih ni mogoče prepisati, in pomnilnik omejimo na ravni storitve.
- V okviru [utrditve strežnika](https://phpsos.de/sl/leistungen/server-haertung/) načrtujemo in preizkusimo prehod na PHP-FPM z ločenimi pooli.


## Pogosta vprašanja

**Kako prepoznam, ali moj strežnik uporablja mod_php?**  
Če ima Apache naložen modul PHP, se v seznamu modulov pojavi kot php_module ali s številko različice v imenu. Dodatno izpis phpinfo pri Server API kaže vnos Apache 2.0 Handler. Tako preskusno datoteko takoj spet izbrišite.

**Zakaj je mod_php pri PHP2Shell posebej kritičen?**  
Po navedbah ekipe PHP je tveganje tam najvišje; exploit je bil prikazan, še preden se sploh izvede koda aplikacije. Zato ne ščiti niti dobro vzdrževana aplikacija. Hitra posodobitev ima zato najvišjo prednost.

**Ali po posodobitvi zadošča ponovno nalaganje Apacheja (reload)?**  
Varen je popoln ponovni zagon storitve, ker je PHP kot modul del procesov Apache. Nato preverite čas zagona vseh procesov Apache. Starejših procesov od posodobitve ne sme ostati.

**Ali je prehod na PHP-FPM zahteven?**  
Praviloma ga je mogoče dobro načrtovati: namestiti PHP-FPM, ustvariti poole, Apache preusmeriti na proxy_fcgi in z načina prefork preiti na drug MPM. To prej preizkusite v kopiji okolja.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI (nemški zvezni urad za informacijsko varnost)](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets (zbirke povzetkov)](https://cheatsheetseries.owasp.org/)