Lyhyesti: php.ini-tietoturvassa on neljä pääaluetta: ei virheilmoituksia ulospäin, turvalliset istuntoevästeet, rajoitetut lataukset ja lukitut arvot, joita sovellukset eivät voi ylikirjoittaa. PHP2Shellin jälkeen lisäksi tulevat php.netin väliaikaiset toimet, ennen kaikkea session.upload_progress.enabled=0. Turvallinen asetuskokonaisuus ei kuitenkaan koskaan korvaa päivitystä.
Miksi php.ini on taas esillä PHP2Shellin jälkeen
php.ini on PHP:n keskeinen asetustiedosto. Monella palvelimella se on kerran konfiguroitu ja sen jälkeen tuskin koskettu. PHP2Shellin myötä tämä on muuttunut: kahteen haavoittuvuuteen CVE-2026-109618 ja CVE-2026-109619 php.net antaa väliaikaisia toimia, jotka vaikuttavat juuri tässä.
Haavoittuvuudet ovat itse PHP-tulkissa. Ne on korjattu versioissa PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35, jotka julkaistiin 21.10.2026. Hyvä asetuskokonaisuus auttaa silti kahdella tavalla: se voi vaikeuttaa hyväksikäyttöä ja rajoittaa vahinkoa, jos jotain pääsee läpi.
Lisäksi monet ylläpitäjät eivät tiedä tarkasti, mitkä asetukset palvelimellaan ovat voimassa. Se on ensimmäinen vaihe.
Mikä php.ini on voimassa palvelimellanne?
PHP voi lukea ajotavasta riippuen eri asetustiedostoja. Komentorivillä, PHP-FPM:llä ja Apachella mod_php:n kanssa on esimerkiksi Debianissa ja Ubuntussa kullakin oma kansionsa hakemistossa /etc/php/<version>/. Jos muutatte vain CLI-tiedostoa, verkkosivustolle ei tapahdu mitään.
# Komentorivin asetustiedostot
php --ini
# PHP-FPM:n asetukset (muokkaa versionumero)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Tarkista yksittäiset arvot PHP-FPM:stä
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Lisäksi arvoja voi olla FPM-poolissa, Apachen asetuksissa, .htaccess-tiedostossa (vain mod_php) tai .user.ini-tiedostossa (FPM ja CGI). Mikä versio palvelimella todella toimii ja onko siinä backport, selvittää artikkeli PHP-version ja korjaustilan tarkistaminen oikein.
Perusasetukset php.ini-tietoturvan parantamiseksi
Seuraavat arvot sopivat useimmille tuotantopalvelimille. Tarkistakaa ennen käyttöönottoa testiympäristössä, toimiiko sovelluksenne kaikilla arvoilla.
; Ei versiotietoa HTTP-otsakkeessa
expose_php = Off
; Kirjaa virheet lokiin, mutta älä koskaan näytä selaimessa
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Älä sisällytä tiedostoja etäosoitteista
allow_url_include = Off
; Jätä allow_url_fopen käyttöön vain, jos sovellus tarvitsee sitä
allow_url_fopen = Off
; Istunnot: tiukka tila, vain HTTPS:n kautta, ei luettavissa JavaScriptillä
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Rajoita suoritusaikaa ja syötteitä
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
Jotkin sovellukset tarvitsevat allow_url_fopen-asetusta päivityksiin tai rajapintoihin. Poistakaa se käytöstä vasta, kun olette tarkistaneet asian. Järjestelmäkomentoja suorittavat funktiot voi lisäksi estää; miten se onnistuu sivuvaikutuksitta, selittää opas disable_functions oikein käytettynä.
php.netin väliaikaiset toimet PHP2Shelliin
Jos ette voi päivittää heti, php.net mainitsee useita asetuksia, jotka pienentävät riskiä. Ne eivät nimenomaisesti ole täydellinen suoja vaan silta päivitykseen.
; Poista Session Upload Progress käytöstä (myös CVE-2026-115560:n vuoksi)
session.upload_progress.enabled = 0
; Rajoita pyynnön kokoa: 8M ilman latauksia, 32M latausten kanssa
post_max_size = 8M
upload_max_filesize = 6M
; Vain PHP 8.5: ei backtraceja vakavissa virheissä
fatal_error_backtraces = 0
Lisäksi php.net suosittelee asettamaan memory_limit=-1 niin, etteivät sovellukset voi ylikirjoittaa arvoa, ja vetämään muistirajan konttien tai cgroupin kautta, ei RLIMIT_AS- tai RLIMIT_DATA-rajoilla. Tämä toimi kuuluu FPM-pooliin tai palvelimen asetuksiin, ja se kannattaa yhdistää toimivaan cgroup-rajaan. Täydellisen yleiskatsauksen löydätte sivulta Pikatoimet, jos ette vielä voi päivittää.
session.upload_progress.enabled=0 toimii vain php.ini-tiedostosta, FPM-poolista tai palvelimen asetuksista annettuna. Jos se asetetaan ini_set()-komennolla tai .user.ini-tiedostossa, toimi ei tehoa. Käynnistäkää sen jälkeen kaikki worker-prosessit uudelleen.
Arvojen lukitseminen ylikirjoittamiselta
Monet sovellukset asettavat omia arvojaan, esimerkiksi muistille tai latauksille. php_admin_value- ja php_admin_flag-asetuksilla lukitsette asetukset niin, etteivät ini_set() eikä .user.ini voi muuttaa niitä. FPM-poolissa se näyttää tältä:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (ote)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Apachessa mod_php:n kanssa sama logiikka pätee php_admin_value- ja php_admin_flag-asetuksilla VirtualHost-asetuksissa. Lataa sen jälkeen palvelu uudelleen ja tarkista aktiivinen arvo:
sudo systemctl reload php8.3-fpm
# Prosessien käynnistysaika: onko se muutoksen jälkeen?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Reload käynnistää PHP-FPM:n worker-prosessit uudelleen. PHP-päivityksen jälkeen tarvitaan sen sijaan kaikkien PHP-prosessien täysi uudelleenkäynnistys, jotta mikään vanha prosessi ei jatka muistissa. Jos samalla palvelimella on useita verkkosivustoja, kannattaa lisäksi käyttää omaa poolia kutakin sivustoa kohden; lisää oppaassa open_basedir ja eristys sivustoittain.
Yleiset virheet ja lyhyt tarkistuslista
Useimmat php.ini-ongelmat eivät johdu vääristä arvoista vaan arvoista väärässä paikassa. Tyypillistä on muutettu CLI-tiedosto, vaikka verkkosivusto toimii PHP-FPM:n kautta. Yhtä usein uudelleenkäynnistys jää muutoksen jälkeen tekemättä, tai hosting-paneeli ylikirjoittaa oman asetuksenne seuraavalla tallennuksella.
Toinen klassikko ovat näkyvät virheilmoitukset tuotantosivustolla. Ne paljastavat polkuja, tietokantojen nimiä tai versioita ja helpottavat hyökkääjien suunnistamista. Etenkin muuton tai uudelleenasennuksen jälkeen display_errors on usein taas arvossa On.
Nämä kohdat kannattaa tarkistaa jokaisen muutoksen ja jokaisen PHP-päivityksen jälkeen:
- Mitä asetustiedostoa verkon ajotapa lukee, ja sisältääkö se arvonne?
- Ovatko
display_errorsjaexpose_phppois päältä, onko virheloki kirjoitettavissa? - Onko
session.upload_progress.enabledarvossa0, asetettuna php.ini-tiedoston tai poolin kautta? - Onko latausten ja pyyntöjen koot rajattu sovellukseen sopiviksi?
- Ovatko kaikkien PHP-prosessien käynnistysajat viimeisen muutoksen jälkeen?
Kirjatkaa tulos päivämäärineen. Näin voitte myöhemmin todistaa, milloin mikäkin asetus oli voimassa.
Miten PHP SOS auttaa konkreettisesti?
- Selvitämme, mikä asetus on todella aktiivinen missäkin ajotavassa.
- Otamme käyttöön yhteensovitetun perusasetuskokonaisuuden ja PHP2Shellin väliaikaiset toimet, testattuna sovelluksellanne.
- Lukitsemme tietoturvan kannalta tärkeät arvot ylikirjoittamiselta ja käynnistämme kaikki worker-prosessit hallitusti uudelleen.
- Dokumentoimme asetukset ja tarkistustuloksen, jotta myöhemmät muutokset pysyvät jäljitettävinä.
Miltä pysyvä suojaus näyttää, kuvaa palvelu PHP-verkkopalvelimen koventaminen.
Usein kysytyt kysymykset
Mitä php.ini-tiedostoa verkkopalvelimeni oikeastaan käyttää?
Se ei useinkaan ole sama kuin komentorivillä. PHP-FPM:llä, Apachella mod_php:n kanssa ja CLI:llä on yleensä omat asetuskansionsa. Tarkistakaa aktiivinen tiedosto siksi kyseisen ajotavan kautta, esimerkiksi komennolla php-fpm -i tai hetkeksi lisätyllä tarkistustiedostolla.
Korvaako turvallinen php.ini PHP-päivityksen?
Ei. Asetukset pienentävät hyökkäyspintaa ja vaikeuttavat hyväksikäyttöä, mutta eivät sulje aukkoa PHP-tulkissa. Myös php.netin PHP2Shell-väliaikaiset toimet ovat nimenomaisesti vain osittainen suoja.
Mitä eroa on php_value- ja php_admin_value-asetuksilla?
Sovellus voi muuttaa php_value-asetuksella asetettuja arvoja ajon aikana. FPM-poolissa tai Apachen asetuksissa php_admin_value-asetuksella annetut arvot on sen sijaan lukittu sovellukselta, myös ini_set()-komennolta ja .user.ini-tiedostolta.
Onko palvelu käynnistettävä uudelleen php.ini-muutoksen jälkeen?
Kyllä. PHP-FPM ja Apache mod_php:n kanssa lukevat asetukset vain käynnistyksen yhteydessä. Uudet arvot ovat voimassa vasta kaikkien koskettujen palvelujen uudelleenkäynnistyksen tai reloadin jälkeen.