Na kratko: Za varnost php.ini so pomembna predvsem štiri področja: nobenih sporočil o napakah navzven, varni piškotki sej, omejena nalaganja in zaklenjene vrednosti, ki jih aplikacije ne morejo prepisati. Po PHP2Shell se dodajo vmesni ukrepi php.net, predvsem session.upload_progress.enabled=0. Varna konfiguracija pa posodobitve nikoli ne nadomesti.
Zakaj je php.ini po PHP2Shell znova v ospredju
Datoteka php.ini je osrednja konfiguracijska datoteka PHP. Na številnih strežnikih je bila enkrat nastavljena in nato skoraj ni bila več spremenjena. S PHP2Shell se je to spremenilo: za ranljivosti CVE-2026-109618 in CVE-2026-109619 php.net navaja vmesne ukrepe, ki posegajo prav tu.
Ranljivosti same so v interpreterju PHP. Odpravljene so v PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35, objavljenih 21. 10. 2026. Dobra konfiguracija kljub temu pomaga na dva načina: izkoriščanje lahko otežijo, in omeji škodo, če kaj vendarle prodre.
Številni upravljavci poleg tega ne vedo natančno, katere nastavitve na njihovem strežniku veljajo. To je prvi korak.
Katera php.ini velja na vašem strežniku?
PHP lahko glede na način delovanja bere različne konfiguracijske datoteke. Ukazna vrstica, PHP-FPM in Apache z mod_php imajo v Debianu in Ubuntuju na primer vsak svojo mapo pod /etc/php/<version>/. Kdor spremeni samo datoteko CLI, na spletni strani ne spremeni ničesar.
# Konfiguracijske datoteke ukazne vrstice
php --ini
# Konfiguracija PHP-FPM (številko različice prilagodite)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Preverite posamezne vrednosti PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Poleg tega so lahko vrednosti v poolu FPM, v konfiguraciji Apache, v .htaccess (samo mod_php) ali v .user.ini (FPM in CGI). Katera različica na strežniku dejansko teče in ali je vsebovan backport, pojasnjuje prispevek Pravilno preverjanje različice PHP in stanja popravkov.
Osnovne nastavitve za večjo varnost php.ini
Naslednje vrednosti so smiselne za večino produkcijskih strežnikov. Pred uporabo v testnem okolju preverite, ali se vaša aplikacija znajde z vsemi vrednostmi.
; Brez navedbe različice v glavi HTTP
expose_php = Off
; Napake beležite v dnevnik, a jih nikoli ne prikazujte v brskalniku
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Ne vključujte datotek z oddaljenih naslovov
allow_url_include = Off
; allow_url_fopen pustite aktiven samo, če ga aplikacija potrebuje
allow_url_fopen = Off
; Seje: striktno, samo prek HTTPS, brez branja z JavaScriptom
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Omejite čas izvajanja in vnose
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
allow_url_fopen nekatere aplikacije potrebujejo za posodobitve ali vmesnike. Izklopite ga samo, če ste to prej preverili. Funkcije, ki izvajajo sistemske ukaze, je mogoče dodatno blokirati; kako to uspe brez stranskih učinkov, pojasnjuje vodnik Pravilna uporaba disable_functions.
Vmesni ukrepi php.net proti PHP2Shell
Če ne morete takoj namestiti popravkov, php.net navaja več nastavitev, ki tveganje znižajo. Izrecno niso popolna zaščita, ampak most do posodobitve.
; Izklopite session upload progress (tudi zaradi CVE-2026-115560)
session.upload_progress.enabled = 0
; Omejite velikost zahteve: 8M brez nalaganj, 32M z nalaganji
post_max_size = 8M
upload_max_filesize = 6M
; Samo PHP 8.5: brez backtraceov pri hudih napakah
fatal_error_backtraces = 0
Poleg tega php.net priporoča, da se memory_limit=-1 nastavi tako, da aplikacije vrednosti ne morejo prepisati, in da se meja pomnilnika namesto prek RLIMIT_AS ali RLIMIT_DATA postavi prek containerja ali cgroup. Ta ukrep sodi v pool FPM ali konfiguracijo strežnika in ga je treba združiti z delujočo mejo cgroup. Celoten pregled najdete na strani Takojšnji ukrepi, če popravkov še ne morete namestiti.
session.upload_progress.enabled=0 deluje samo iz php.ini, poola FPM ali konfiguracije strežnika. Če je nastavljen prek ini_set() ali .user.ini, ukrep ne učinkuje. Nato znova zaženite vse workerje.
Zaklenite vrednosti pred prepisovanjem
Številne aplikacije nastavijo lastne vrednosti, na primer za pomnilnik ali nalaganja. S php_admin_value in php_admin_flag nastavitve določite tako, da jih ne more spremeniti ne ini_set() ne .user.ini. V poolu FPM je to videti tako:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (izvleček)
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
Pri Apacheju z mod_php velja ista logika s php_admin_value in php_admin_flag v konfiguraciji VirtualHost. Nato storitev znova naložite in aktivno vrednost preverite:
sudo systemctl reload php8.3-fpm
# Čas zagona procesov: je po spremembi?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Reload znova zažene workerje PHP-FPM. Po posodobitvi PHP pa je potreben popoln ponovni zagon vseh procesov PHP, da v pomnilniku ne teče noben star proces. Pri več spletnih straneh na enem strežniku se poleg tega splača imeti poseben pool za vsako stran, več o tem v vodniku open_basedir in izolacija po spletnih straneh.
Pogoste napake in kratek kontrolni seznam
Večina težav s php.ini ne nastane zaradi napačnih vrednosti, ampak zaradi vrednosti na napačnem mestu. Značilna je spremenjena datoteka CLI, medtem ko spletna stran teče prek PHP-FPM. Prav tako pogosto po spremembi izostane ponovni zagon ali pa upravljalni panel gostovanja ob naslednjem shranjevanju prepiše lastno nastavitev.
Druga klasika so vidna sporočila o napakah na živi spletni strani. Izdajo poti, imena podatkovnih zbirk ali različice in napadalcem olajšajo orientacijo. Prav po selitvi ali novi namestitvi je display_errors pogosto znova na On.
Te točke preverite po vsaki spremembi in po vsaki posodobitvi PHP:
- Katero konfiguracijsko datoteko bere spletni način delovanja in ali vsebuje vaše vrednosti?
- Sta
display_errorsinexpose_phpizklopljena in ali je v dnevnik napak mogoče pisati? - Je
session.upload_progress.enablednastavljen na0, prek php.ini ali poola? - So velikosti nalaganj in zahtev omejene v skladu z aplikacijo?
- Ali imajo vsi procesi PHP čas zagona po zadnji spremembi?
Rezultat zabeležite z datumom. Tako je pozneje mogoče dokazati, kdaj je katera nastavitev veljala.
Kako PHP SOS pomaga konkretno?
- Ugotovimo, katera konfiguracija je v katerem načinu delovanja dejansko aktivna.
- Uvedemo usklajeno osnovno konfiguracijo in vmesne ukrepe PHP2Shell, preizkušene z vašo aplikacijo.
- Varnostno pomembne vrednosti zaklenemo pred prepisovanjem in nadzorovano znova zaženemo vse workerje.
- Nastavitve in rezultat preverjanja dokumentiramo, da poznejše spremembe ostanejo sledljive.
Kako izgleda trajna zaščita, opisuje storitev Utrjevanje strežnikov PHP.
Pogosta vprašanja
Katero php.ini pravzaprav uporablja moj spletni strežnik?
To pogosto ni ista datoteka kot v ukazni vrstici. PHP-FPM, Apache z mod_php in CLI imajo praviloma vsak svojo konfiguracijsko mapo. Aktivno datoteko zato preverite prek ustreznega načina delovanja, na primer s php-fpm -i ali s kratkotrajno odloženo preizkusno datoteko.
Ali varen php.ini nadomesti posodobitev PHP?
Ne. Nastavitve zmanjšajo napadalno površino in otežijo izkoriščanje, vendar ne zaprejo ranljivosti v interpreterju PHP. Tudi vmesni ukrepi php.net za PHP2Shell izrecno niso popolna zaščita.
Kakšna je razlika med php_value in php_admin_value?
Vrednosti, nastavljene s php_value, lahko aplikacija med izvajanjem znova spremeni. Vrednosti prek php_admin_value v poolu FPM ali konfiguraciji Apache pa so za aplikacijo zaklenjene, tudi za ini_set() in .user.ini.
Ali moram po spremembi php.ini znova zagnati strežnik?
Da. PHP-FPM in Apache z mod_php konfiguracijo preberejo samo ob zagonu. Nove vrednosti veljajo šele po ponovnem zagonu ali reloadu vseh zadevnih storitev.