# Apache ja mod_php turvamine

> Apache mod_php pärast PHP2Shelli: tuvastage töörežiim, paigake PHP moodul, käivitage Apache täielikult uuesti ja valmistage ette üleminek PHP-FPM-ile.

Allikas: https://phpsos.de/et/server/apache-mod-php/  
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:** Apache'i ja mod_php puhul töötab PHP otse veebiserveris. PHP meeskond hindab PHP2Shelli riski just selles töörežiimis kõige suuremaks, sest ekspluateerimine näidati ära enne, kui rakenduse kood üldse käivitub. Paigake kohe, käivitage Apache täielikult uuesti ja planeerige seejärel üleminek PHP-FPM-ile.

## Mis on mod_php ja miks see praegu loeb

mod_php puhul laadib Apache PHP mooduli igasse oma töötlusprotsessi. Iga päring PHP failile käivitatakse otse selles protsessis. See oli pikka aega standard ja on lihtne seadistada. Kuid see tähendab ka: kõik serveri veebisaidid töötavad sama kasutajaga ning PHP jagab protsessi veebiserveriga.

PHP2Shell hõlmab turvauke CVE-2026-109618 ja CVE-2026-109619, mõlemad CVSS v4.0 hindega 9,2. Teise puhul võib päringu sisemine olek jääda pärast mälu vabastamist alles ja seda võib kasutada hilisem päring samas protsessis. mod_php puhul tuvastas PHP meeskond kõrgeima riski. Tausta ja hinnangu leiate lehelt [Miks mod_php kannab kõrgeimat riski](https://phpsos.de/et/php2shell/mod-php-risiko/).

## Tuvastage Apache mod_php ja kontrollige versiooni

Kontrollige kõigepealt, kas teie Apache kasutab mod_php-d üldse. Järgmised käsud ainult loevad. Käskude ja pakettide nimed erinevad distributsiooniti ja on näited.

```bash
# Debian/Ubuntu: laaditud moodulid
apache2ctl -M 2>/dev/null | grep -i php

# RHEL-i perekond
httpd -M 2>/dev/null | grep -i php

# Milline MPM on aktiivne? mod_php eeldab prefork'i
apache2ctl -V 2>/dev/null | grep -i mpm

# Mooduli paketi seis (näited)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
```

Kui ilmub moodul nagu `php_module`, töötab mod_php. Üksnes kuvatav PHP versioon ei ole paiga tõend, sest distributsioonid paigaldavad parandusi sageli backportina. PHP projekti parandatud versioonid on 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Distributsioonipakettide puhul loeb CVE-numbritega muudatuslogi.

## Paigake ja käivitage Apache täielikult uuesti

Paigaldage uuendus paketihalduse kaudu. Kuna PHP asub Apache'i protsessis, peab seejärel kogu teenus uuesti käivituma. Seadistuse uuestilaadimine ei ole siin kindel tee.

```bash
# Debian/Ubuntu
systemctl restart apache2

# RHEL-i perekond
systemctl restart httpd

# Kontroll: kõigi Apache'i protsesside käivitusaeg
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Kõigi Apache'i protsesside käivitusaeg peab olema pärast uuendust. Kui samas serveris töötab lisaks PHP-FPM või php-cgi, käivitage ka need teenused uuesti.

> **Tegutsege kohe:**
> Kui teie PHP versiooni jaoks pole veel paika, soovitab BSI veebiserver ajutiselt võrgust lahti ühendada. mod_php puhul kaalub see eriti raskelt, sest rünnak võib toimida enne rakenduse koodi.

## Ajutised meetmed Apache'i seadistuses

php.net nimetab ajutisi meetmeid, mis vähendavad riski, kuid ei paku täielikku kaitset. mod_php puhul seadke väärtused Apache'i seadistuses käskudega `php_admin_value` ja `php_admin_flag`, et `.htaccess` ja rakendused neid üle kirjutada ei saaks.

```apache
# Näide: VirtualHosti või serveri tasemel seadistuses
<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>
```

Üleslaadimisfunktsiooniga nimetab php.net `post_max_size = 32M`, `upload_max_filesize` sellest väiksem. PHP 8.5 puhul lisandub `fatal_error_backtraces=0`. Märkuse `memory_limit=-1` kohta rakendage seda ainult koos teenuse mälupiiranguga cgroupide kaudu, näiteks `MemoryMax` abil systemd täiendusfailis, mitte `RLIMIT_AS` või `RLIMIT_DATA` kaudu. Seejärel käivitage Apache täielikult uuesti. Kõik meetmed ülevaatlikult: [Kohesed meetmed ilma paigata](https://phpsos.de/et/php2shell/sofortmassnahmen-ohne-patch/).

## Tee mod_php-st ära

Pärast ägedat paikamist tasub üle minna PHP-FPM-ile. Seal töötab PHP oma protsessides, veebiserverist eraldi. Iga veebisait võib saada oma pooli oma kasutajaga, piire saab seada poolide kaupa ja taaskäivitused puudutavad ainult PHP-d. Apache ühendab PHP-FPM-i mooduliga `mod_proxy_fcgi` ning saab prefork'i asemel kasutada kaasaegsemat MPM-i, näiteks event.

Planeerige vahetus testkeskkonnas: looge igale veebisaidile pool, kohandage failiõigused uutele kasutajatele, viige `.htaccess` kirjed `php_value` poolide sätetesse, tehke koormustestid. Kuidas näeb välja korralik ülesehitus, näitab leht [Nginx ja PHP-FPM turvamine](https://phpsos.de/et/server/nginx-php-fpm/); põhimõtted kehtivad võrdselt ka Apache'i ja PHP-FPM-i puhul.

Sõltumata töörežiimist kehtib: paik ei eemalda juba sisse toodud pahavara. Säilitage logid alates 20.10.2026 ja kontrollige serverit jälgede suhtes.

Jälgede otsimisel mod_php serverites tasub vaadata ühist kasutajat. Kuna kõik veebisaidid töötavad Apache'i kasutaja all, näiteks `www-data` või `apache`, saab ründaja, kes on ühe veebisaidi üle võtnud, reeglina lugeda ja muuta ka teiste faile. Kontrollige seetõttu mitte ainult veebisaiti, mis teile kahtlane tundub, vaid kõiki serveri Document-Root'e. Pöörake erilist tähelepanu värske muutmiskuupäevaga PHP failidele üleslaadimis- ja vahemälukataloogides, programmikoodile, mis kuulub Apache'i kasutajale, ning tundmatutele kirjetele selle kasutaja crontab'is. Kui leiate midagi, kindlustage esmalt seis ja ärge kustutage kiirustades, et põhjus jääks hiljem jälgitavaks.

## Kuidas PHP SOS konkreetselt aitab?

- Kontrollime töörežiimi, MPM-i ja paketi seisu ning hindame, kas teie server on tegelikult paigatud.
- [PHP paikamisteenuse](https://phpsos.de/et/leistungen/php-patch-service/) kaudu paigaldame uuenduse, käivitame Apache'i täielikult uuesti ja dokumenteerime tõendi.
- Kuni paigani seame ajutised meetmed üle kirjutamatult ja piirame mälu teenuse tasemel.
- [Serveri karastamise](https://phpsos.de/et/leistungen/server-haertung/) raames planeerime ja testime ülemineku PHP-FPM-ile eraldi poolidega.


## Korduma kippuvad küsimused

**Kuidas ma saan teada, kas minu server kasutab mod_php-d?**  
Kui Apache'il on PHP moodul laaditud, ilmub see moodulite loendis nimega php_module või versiooninumbriga nimes. Lisaks näitab phpinfo väljund real Server API kirjet Apache 2.0 Handler. Kustutage selline testfail kohe uuesti.

**Miks on mod_php PHP2Shelli puhul eriti kriitiline?**  
PHP meeskonna andmetel on risk seal kõige suurem; ekspluateerimine näidati ära enne, kui rakenduse kood üldse käivitub. Seetõttu ei kaitse isegi hästi hooldatud rakendus. Kiire uuendus on seepärast esmatähtis.

**Kas pärast uuendust piisab Apache'i reloadist?**  
Kindel on teenuse täielik taaskäivitus, sest PHP asub moodulina Apache'i protsessides. Kontrollige seejärel kõigi Apache'i protsesside käivitusaega. Uuendusest vanemaid protsesse ei tohi alles jääda.

**Kas üleminek PHP-FPM-ile on keerukas?**  
Enamasti on see hästi planeeritav: paigaldada PHP-FPM, luua poolid, seadistada Apache proxy_fcgi peale ja vahetada prefork mõne teise MPM-i vastu. Testige seda enne keskkonna koopias.

## Allikad

- [php.net: turvateated](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)