Trumpai: php.ini saugai svarbios keturios sritys: jokių klaidų pranešimų išorėje, saugūs sesijų slapukai, apriboti įkėlimai ir užrakintos reikšmės, kurių programos negali perrašyti. Po PHP2Shell prisideda php.net pereinamosios priemonės, visų pirma session.upload_progress.enabled=0. Saugi konfigūracija vis dėlto niekada nepakeičia atnaujinimo.
Kodėl po PHP2Shell php.ini vėl atsiduria dėmesio centre
php.ini yra pagrindinis PHP konfigūracijos failas. Daugelyje serverių jis kartą sukonfigūruotas ir po to vos liestas. Su PHP2Shell tai pasikeitė: dviem pažeidžiamumams, CVE-2026-109618 ir CVE-2026-109619, php.net nurodo pereinamąsias priemones, kurios veikia būtent čia.
Patys pažeidžiamumai yra PHP interpretatoriuje. Ištaisyti PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijose, išleistose 2026-10-21. Gera konfigūracija vis dėlto padeda dviem būdais: ji gali apsunkinti išnaudojimą ir riboja žalą, jei kas nors vis dėlto prasiskverbia.
Be to, daugelis operatorių tiksliai nežino, kokie nustatymai galioja jų serveryje. Tai pirmasis žingsnis.
Kuris php.ini galioja jūsų serveryje?
Priklausomai nuo veikimo režimo, PHP gali skaityti skirtingus konfigūracijos failus. Komandinė eilutė, PHP-FPM ir Apache su mod_php Debian ir Ubuntu sistemose, pavyzdžiui, turi savus aplankus po /etc/php/<version>/. Kas keičia tik CLI failą, svetainei nieko nepakeičia.
# Konfigūracijos failai komandinėje eilutėje
php --ini
# PHP-FPM konfigūracija (pritaikykite versijos numerį)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# PHP-FPM atskirų reikšmių patikra
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Be to, reikšmės gali būti FPM baseine, Apache konfigūracijoje, .htaccess (tik mod_php) arba .user.ini (FPM ir CGI). Kokia versija serveryje iš tikrųjų veikia ir ar yra backport, paaiškina straipsnis Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
Pagrindiniai nustatymai didesniam php.ini saugumui
Toliau nurodytos reikšmės daugumai produkcinių serverių prasmingos. Prieš naudodami išbandykite testinėje aplinkoje, ar jūsų programa su visomis reikšmėmis veikia.
; Be versijos nuorodos HTTP antraštėje
expose_php = Off
; Klaidas registruoti, bet niekada nerodyti naršyklėje
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Neįtraukti failų iš nuotolinių adresų
allow_url_include = Off
; allow_url_fopen palikti aktyvų tik jei programai reikia
allow_url_fopen = Off
; Sesijos: griežtos, tik per HTTPS, JavaScript neperskaitomos
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Apriboti vykdymo laiką ir įvestis
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
allow_url_fopen kai kurioms programoms reikia atnaujinimams ar sąsajoms. Išjunkite jį tik tada, kai tai iš anksto patikrinote. Funkcijas, vykdančias sistemos komandas, galima papildomai užblokuoti; kaip tai padaryti be šalutinių poveikių, paaiškina vadovas Kaip teisingai naudoti disable_functions.
php.net pereinamosios priemonės dėl PHP2Shell
Jei negalite pataisyti iš karto, php.net nurodo kelis nustatymus, mažinančius riziką. Jie aiškiai nėra visiška apsauga, o tik tiltas iki atnaujinimo.
; Išjungti session upload progress (taip pat dėl CVE-2026-115560)
session.upload_progress.enabled = 0
; Apriboti užklausos dydį: 8M be įkėlimų, 32M su įkėlimais
post_max_size = 8M
upload_max_filesize = 6M
; Tik PHP 8.5: be atsekimų (backtrace) sunkių klaidų atveju
fatal_error_backtraces = 0
Be to, php.net rekomenduoja nustatyti memory_limit=-1 taip, kad programos negalėtų šios reikšmės perrašyti, o atminties ribą nustatyti per konteinerį ar cgroup, o ne per RLIMIT_AS ar RLIMIT_DATA. Ši priemonė priklauso FPM baseinui arba serverio konfigūracijai ir turėtų būti derinama su veikiančia cgroup riba. Visą apžvalgą rasite puslapyje Skubios priemonės, kai dar negalite pataisyti.
session.upload_progress.enabled=0 veikia tik nustatytas php.ini, FPM baseine arba serverio konfigūracijoje. Nustatyta per ini_set() ar .user.ini, priemonė neveikia. Po to iš naujo paleiskite visus darbinius procesus (worker).
Reikšmių užrakinimas nuo perrašymo
Daugelis programų nustato savo reikšmes, pavyzdžiui, atminties ar įkėlimų. Su php_admin_value ir php_admin_flag nustatymus užfiksuojate taip, kad jų nepakeistų nei ini_set(), nei .user.ini. FPM baseine tai atrodo taip:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (ištrauka)
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
Apache su mod_php galioja ta pati logika su php_admin_value ir php_admin_flag VirtualHost konfigūracijoje. Po to perkraukite tarnybą ir patikrinkite aktyvią reikšmę:
sudo systemctl reload php8.3-fpm
# Procesų paleidimo laikas: ar jis vėlesnis už pakeitimą?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Perkrovimas (reload) iš naujo paleidžia PHP-FPM darbinius procesus. Po PHP atnaujinimo, priešingai, reikia pilnai iš naujo paleisti visus PHP procesus, kad atmintyje neliktų seno proceso. Kai viename serveryje yra kelios svetainės, taip pat verta kiekvienai svetainei turėti atskirą baseiną; daugiau vadove open_basedir ir izoliacija kiekvienai svetainei.
Dažnos klaidos ir trumpas kontrolinis sąrašas
Dauguma problemų su php.ini kyla ne dėl netinkamų reikšmių, o dėl reikšmių netinkamoje vietoje. Tipiška klaida: pakeistas CLI failas, o svetainė veikia per PHP-FPM. Taip pat dažnai po pakeitimo nepaleidžiama iš naujo arba hostingo skydelis kitą kartą išsaugodamas perrašo jūsų nustatymą.
Antras klasikinis atvejis yra matomi klaidų pranešimai gyvoje svetainėje. Jie atskleidžia kelius, duomenų bazių pavadinimus ar versijas ir palengvina užpuolikams orientavimąsi. Būtent po perkėlimo ar naujo įdiegimo display_errors dažnai vėl būna On.
Šiuos punktus patikrinkite po kiekvieno pakeitimo ir po kiekvieno PHP atnaujinimo:
- Kurį konfigūracijos failą skaito žiniatinklio veikimo režimas ir ar jame yra jūsų reikšmės?
- Ar
display_errorsirexpose_phpišjungti, ar klaidų žurnalas įrašomas? - Ar
session.upload_progress.enabledyra0, nustatytas per php.ini ar baseiną? - Ar įkėlimų ir užklausų dydžiai apriboti pagal programą?
- Ar visų PHP procesų paleidimo laikas vėlesnis už paskutinį pakeitimą?
Rezultatą užfiksuokite su data. Taip vėliau bus galima įrodyti, kada koks nustatymas galiojo.
Kaip PHP SOS padeda konkrečiai?
- Nustatome, kokia konfigūracija kokiame veikimo režime iš tikrųjų aktyvi.
- Įgyvendiname suderintą pagrindinę konfigūraciją ir PHP2Shell pereinamąsias priemones, išbandytas su jūsų programa.
- Saugumui svarbias reikšmes užrakiname nuo perrašymo ir kontroliuojamai iš naujo paleidžiame visus darbinius procesus.
- Nustatymus ir patikros rezultatą dokumentuojame, kad vėlesni pakeitimai išliktų atsekami.
Kaip atrodo ilgalaikė apsauga, aprašo paslauga PHP žiniatinklio serverių sutvirtinimas.
Dažni klausimai
Kurį php.ini failą iš tikrųjų naudoja mano žiniatinklio serveris?
Dažnai tai ne tas pats, kaip komandinėje eilutėje. PHP-FPM, Apache su mod_php ir CLI paprastai turi savus konfigūracijos aplankus. Todėl aktyvų failą tikrinkite per atitinkamą veikimo režimą, pavyzdžiui, su php-fpm -i arba trumpam padėtu patikros failu.
Ar saugus php.ini pakeičia PHP atnaujinimą?
Ne. Nustatymai sumažina atakos paviršių ir apsunkina išnaudojimą, bet neuždaro pažeidžiamumo PHP interpretatoriuje. Net php.net pereinamosios priemonės dėl PHP2Shell aiškiai nėra visiška apsauga.
Kuo skiriasi php_value ir php_admin_value?
Su php_value nustatytas reikšmes programa vykdymo metu gali vėl pakeisti. Per php_admin_value FPM baseine ar Apache konfigūracijoje nustatytos reikšmės programai užrakintos, taip pat ir nuo ini_set() bei .user.ini.
Ar pakeitus php.ini reikia paleisti iš naujo?
Taip. PHP-FPM ir Apache su mod_php konfigūraciją skaito tik paleidimo metu. Naujos reikšmės galioja tik iš naujo paleidus arba perkrovus visas paveiktas tarnybas.