Apache ja mod_php turvamine

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.

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.

# 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.

# 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.

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.

# 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.

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; 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 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 raames planeerime ja testime ülemineku PHP-FPM-ile eraldi poolidega.

Korduma kippuvad küsimused

Allikad

• php.net: turvateated
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets