Apache mod_php:n suojaus

Lyhyesti: Apachella ja mod_php:llä PHP toimii suoraan verkkopalvelimessa. PHP-tiimi arvioi PHP2Shellin riskin korkeimmaksi juuri tässä toimintatavassa, koska hyökkäyskoodi on osoitettu toimivaksi jo ennen kuin sovelluskoodi käynnistyy. Korjaa heti, käynnistä Apache kokonaan uudelleen ja suunnittele sen jälkeen siirtymä PHP-FPM:ään.

Mikä mod_php on ja miksi sillä on nyt merkitystä

mod_php:ssä Apache lataa PHP:n moduulina jokaiseen omaan työprosessiinsa. Jokainen PHP-tiedostoon kohdistuva pyyntö suoritetaan suoraan tässä prosessissa. Pitkään tämä oli vakio ja se on helppo ottaa käyttöön. Se tarkoittaa kuitenkin myös: kaikki palvelimen verkkosivustot toimivat saman käyttäjän alla, ja PHP jakaa prosessin verkkopalvelimen kanssa.

PHP2Shell koostuu haavoittuvuuksista CVE-2026-109618 ja CVE-2026-109619, kummankin CVSS v4.0 9.2. Jälkimmäisessä pyynnön sisäinen tila voi jäädä voimaan muistin vapauttamisen jälkeen ja myöhempi pyyntö samassa prosessissa voi hyödyntää sitä. mod_php:n osalta PHP-tiimi on todennut korkeimman riskin. Tausta ja arviointi ovat sivulla Miksi mod_php kantaa korkeimman riskin.

Tunnista Apache mod_php ja tarkista versio

Tarkista ensin, käyttääkö Apachesi ylipäätään mod_php:tä. Seuraavat komennot vain lukevat. Komentojen ja pakettien nimet vaihtelevat jakelun mukaan ja ovat esimerkkejä.

# Debian/Ubuntu: ladatut moduulit
apache2ctl -M 2>/dev/null | grep -i php

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

# Mikä MPM on aktiivinen? mod_php edellyttää preforkin
apache2ctl -V 2>/dev/null | grep -i mpm

# Moduulin pakettitila (esimerkkejä)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Jos näkyy moduuli kuten php_module, mod_php on käytössä. Näytetty PHP-versio ei yksin todista korjausta, koska jakelut asentavat korjauksia usein backport-korjauksina. PHP-projektin korjatut versiot ovat 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Jakelupaketeissa ratkaisee muutosloki CVE-numeroineen.

Korjaa ja käynnistä Apache kokonaan uudelleen

Asenna päivitys paketinhallinnan kautta. Koska PHP on Apache-prosessissa, koko palvelu on sen jälkeen käynnistettävä uudelleen. Konfiguraation uudelleenlataus ei ole tässä varma tapa.

# Debian/Ubuntu
systemctl restart apache2

# RHEL-perhe
systemctl restart httpd

# Tarkistus: kaikkien Apache-prosessien käynnistysaika
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Kaikkien Apache-prosessien käynnistysajan on oltava päivityksen jälkeinen. Jos samalla palvelimella pyörii lisäksi PHP-FPM tai php-cgi, käynnistä myös nämä palvelut uudelleen.

Väliaikaiset toimenpiteet Apachen konfiguraatiossa

php.net mainitsee väliaikaisia toimenpiteitä, jotka pienentävät riskiä mutta eivät tarjoa täydellistä suojaa. mod_php:n kohdalla arvot asetetaan Apachen konfiguraatiossa php_admin_value- tai php_admin_flag-direktiiveillä, jolloin .htaccess ja sovellukset eivät voi ylikirjoittaa niitä.

# Esimerkki: VirtualHost- tai palvelinlaajuisessa konfiguraatiossa
<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>

Latausominaisuuden kanssa php.net mainitsee arvon post_max_size = 32M ja upload_max_filesize sen alapuolella. PHP 8.5:ssä lisätään fatal_error_backtraces=0. Ohjeen memory_limit=-1 toteutat vain yhdessä palvelun muistirajan kanssa cgroupien kautta, esimerkiksi MemoryMax-asetuksella systemd-lisäyksessä, ei RLIMIT_AS- tai RLIMIT_DATA-asetuksilla. Sen jälkeen Apache käynnistetään kokonaan uudelleen. Kaikki toimenpiteet yhteenvetona: Pikatoimet ilman korjausta.

Tie pois mod_php:stä

Akuutin korjauksen jälkeen siirtyminen PHP-FPM:ään kannattaa. Silloin PHP toimii omissa prosesseissaan, erillään verkkopalvelimesta. Jokaiselle verkkosivustolle voi antaa oman poolin ja oman käyttäjän, rajat voi asettaa poolikohtaisesti, ja uudelleenkäynnistykset koskevat vain PHP:tä. Apache liittää PHP-FPM:n mod_proxy_fcgi-moduulilla ja voi silloin käyttää preforkin sijaan modernimpaa MPM:ää, kuten eventiä.

Suunnittele vaihto testiympäristössä: luo jokaiselle verkkosivustolle oma pooli, sovita tiedosto-oikeudet uusille käyttäjille, siirrä .htaccess-tiedostojen php_value-merkinnät pooliasetuksiin ja tee kuormitustestit. Siistin rakenteen näyttää Nginx ja PHP-FPM turvalliseksi; periaatteet pätevät yhtä lailla Apachelle PHP-FPM:n kanssa.

Toimintatavasta riippumatta pätee: korjaus ei poista jo asennettua haittaohjelmaa. Säilytä lokit 20.10.2026 alkaen ja tarkista palvelimen jäljet.

Jälkien etsinnässä mod_php-palvelimilla kannattaa katsoa yhteistä käyttäjää. Koska kaikki verkkosivustot toimivat Apache-käyttäjän alla, esimerkiksi www-data tai apache, hyökkääjä, joka on ottanut haltuunsa yhden verkkosivuston, voi yleensä lukea ja muuttaa myös muiden tiedostoja. Tarkista siksi paitsi se verkkosivusto, joka vaikuttaa epäilyttävältä, myös kaikki palvelimen Document Rootit. Kiinnitä erityistä huomiota PHP-tiedostoihin, joiden muutospäivä on tuore, latausten ja välimuistin hakemistoissa, ohjelmakoodiin, jonka omistaa Apache-käyttäjä, ja tuntemattomiin merkintöihin tämän käyttäjän crontabissa. Jos löydät jotakin, tallenna ensin tila äläkä poista hätiköiden, jotta syy säilyy myöhemmin jäljitettävänä.

Miten PHP SOS auttaa konkreettisesti?

• Tarkistamme toimintatavan, MPM:n ja pakettitilan ja arvioimme, onko palvelimenne todella korjattu.
• PHP-korjauspalvelun kautta asennamme päivityksen, käynnistämme Apachen kokonaan uudelleen ja dokumentoimme todisteen.
• Korjaukseen asti asetamme väliaikaiset toimenpiteet ylikirjoittamattomina ja rajoitamme muistin palvelutasolla.
• Palvelimen koventamisen puitteissa suunnittelemme ja testaamme siirtymän PHP-FPM:ään erillisillä pooleilla.

Usein kysytyt kysymykset

Lähteet

• php.net: tietoturvatiedotteet
• PHP 8 ChangeLog (muutosloki)
• BSI (Saksan liittovaltion tietoturvavirasto)
• OWASP Cheat Sheets (ohjekortit)