# Apache mod_php:n suojaus > Apache mod_php PHP2Shellin jälkeen: tunnista toimintatapa, korjaa PHP-moduuli, käynnistä Apache kokonaan uudelleen ja valmistele siirtymä PHP-FPM:ään. Lähde: https://phpsos.de/fi/server/apache-mod-php/ Tilanne: 25.10.2026 Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6 **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](https://phpsos.de/fi/php2shell/mod-php-risiko/). ## 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ä. ```bash # 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. ```bash # 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. > **Toimi heti:** > Jos PHP-versiollesi ei ole vielä korjausta, BSI suosittelee ottamaan verkkopalvelimen tilapäisesti pois verkosta. mod_php:n kohdalla tämä painaa erityisesti, koska hyökkäys voi toimia ennen sovelluskoodia. ## 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ä. ```apache # Esimerkki: VirtualHost- tai palvelinlaajuisessa konfiguraatiossa php_admin_flag session.upload_progress.enabled off php_admin_value post_max_size 8M php_admin_value upload_max_filesize 6M ``` 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](https://phpsos.de/fi/php2shell/sofortmassnahmen-ohne-patch/). ## 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](https://phpsos.de/fi/server/nginx-php-fpm/); 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](https://phpsos.de/fi/leistungen/php-patch-service/) 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](https://phpsos.de/fi/leistungen/server-haertung/) puitteissa suunnittelemme ja testaamme siirtymän PHP-FPM:ään erillisillä pooleilla. ## Usein kysytyt kysymykset **Mistä tiedän, käyttääkö palvelimeni mod_php:tä?** Jos Apacheen on ladattu PHP-moduuli, se näkyy moduuliluettelossa nimellä php_module tai versionumeron sisältävänä nimenä. Lisäksi phpinfo-tuloste näyttää kohdassa Server API merkinnän Apache 2.0 Handler. Poista tällainen testitiedosto heti. **Miksi mod_php on PHP2Shellin kohdalla erityisen kriittinen?** PHP-tiimin mukaan riski on siellä suurin; hyökkäyskoodi on osoitettu toimivaksi jo ennen kuin sovelluskoodi ylipäätään käynnistyy. Siksi hyvin ylläpidettykään sovellus ei suojaa. Nopealla päivityksellä on korkein prioriteetti. **Riittääkö Apachen reload päivityksen jälkeen?** Varma tapa on palvelun täysi uudelleenkäynnistys, koska PHP on moduulina Apache-prosesseissa. Tarkista sen jälkeen kaikkien Apache-prosessien käynnistysaika. Päivitystä vanhempia prosesseja ei saa jäädä jäljelle. **Onko siirtyminen PHP-FPM:ään työlästä?** Yleensä se on hyvin suunniteltavissa: asenna PHP-FPM, luo poolit, vaihda Apache käyttämään proxy_fcgi:tä ja siirry prefork-MPM:stä toiseen. Testaa se ensin ympäristön kopiossa. ## Lähteet - [php.net: tietoturvatiedotteet](https://www.php.net/) - [PHP 8 ChangeLog (muutosloki)](https://www.php.net/ChangeLog-8.php) - [BSI (Saksan liittovaltion tietoturvavirasto)](https://www.bsi.bund.de/) - [OWASP Cheat Sheets (ohjekortit)](https://cheatsheetseries.owasp.org/)