Lühidalt: Ajutine lahendus PHP turvaaugule PHP2Shell võib riski vähendada, kuid ei asenda uuendust. php.net nimetab selleks kindlaid mälu- ja üleslaadimispiire, Session Upload Progress'i väljalülitamist ning PHP 8.5-l fatal_error_backtraces=0. Kui seegi lühikese aja jooksul ei õnnestu, soovitab BSI veebiserveri ajutiselt võrgust maha võtta.
Mida ajutine lahendus saab ja mida mitte
php.net-i ajutised meetmed peavad raskendama tingimusi, mille korral turvaauke CVE-2026-109618 ja CVE-2026-109619 saab ära kasutada. Need ei ole selgesõnaliselt täielik kaitse. Turvaaugud on parandatud ainult versioonides PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 või teie pakkuja kinnitatud tagasiportimises.
Meetmed on mõistlikud, kui uuendus ei õnnestu veel konkreetsel põhjusel: hooldusaken on alles ees, rakendus tuleb enne testida või kasutate PHP 8.1 või vanemat, mille jaoks ametlikku uuendust enam pole. Siis on need sild, mitte eesmärk.
Planeerige seetõttu ajutise lahendusega koos ka uuendus: kes selle ellu viib, millises hooldusaknas ja kes kontrollib pärast, et kõik tööprotsessid on uuesti käivitatud? Üleminek ilma lõppkuupäevata kipub muutuma püsiseisundiks.
Variant 1: server ajutiselt võrgust maha
BSI on välja kuulutanud hoiatustaseme 3 (oranž) ja soovitab mõjutatud veebiserverid ajutiselt võrgust maha võtta, kui uuendus ei ole kohe võimalik. Mõned pakkujad on seda ettevaatusest teinud; see ei tähenda, et need veebisaidid oleks häkitud.
Paljudele ettevõtetele on poe või portaali rike kallis. Kaalumine võib olla mõistlik: ligipääs ainult VPN-i või lubatud IP-aadresside kaudu, staatiline hooldusleht PHP rakenduse asemel või üksikute, mittevajalike veebisaitide väljalülitamine serveris. Mida vähem PHP-d väljastpoolt kättesaadav on, seda väiksem on ründepind.
Oluline on otsus teadlikult teha ja fikseerida: kes otsustas millal server võrku jätta ja milliste kaitsemeetmetega? See aitab hiljem kindlustaja, andmekaitse ja juhtkonna ees.
php.net-i ajutised meetmed
| Meede | Väärtus | Märkus |
|---|---|---|
memory_limit |
-1, üle kirjutamatu |
mälupiirang siis konteineri või cgroupi kaudu |
post_max_size |
8M ilma üleslaadimisteta, 32M üleslaadimistega |
upload_max_filesize sellest väiksem |
| Mälupiirang | konteineri/cgroupi kaudu | mitte RLIMIT_AS või RLIMIT_DATA kaudu |
session.upload_progress.enabled |
0 |
php.ini-s, poolis või serveri seadistuses, mitte ini_set() ega .user.ini kaudu |
fatal_error_backtraces |
0 |
ainult PHP 8.5 |
Säte session.upload_progress.enabled=0 on ühtlasi abinõu 23. oktoobril teatatud turvaaugu CVE-2026-115560 vastu.
PHP turvaaugu ajutise lahenduse õige seadmine
Otsustav on koht. Väärtused tuleb seada nii, et rakendus ei saa neid üle kirjutada. Teed ja teenuste nimed erinevad distributsiooniti; näited lähtuvad PHP 8.3-st.
PHP-FPM, poolis (nt /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; ainult PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache koos mod_php-ga, serveri seadistuses või VirtualHostis:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Mälupiirang cgroupi kaudu, siin systemd abil FPM-i teenusele. Kohandage väärtust oma serverile:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Seejärel käivitage kõik tööprotsessid uuesti, muidu ei rakendu ükski neist: systemctl restart php8.3-fpm või mod_php puhul Apache. Kuidas kontrollida, et ükski vana protsess enam ei tööta, on kirjas lehel PHP-FPM-i ja kõigi tööprotsesside taaskäivitus. Seadistuse üldist karastamist kirjeldab php.ini turvaline seadistamine.
Testige pärast ümberlülitust üleslaadimisi ja suuri vorme. Liiga napp post_max_size võib blokeerida tellimusi, kandideerimisvorme või meedia üleslaadimisi. See on üks põhjus uuendust mitte kaua edasi lükata.
Täiendavad kaitsekihid
Veebirakenduste tulemüür või virtuaalne paikamine võib aidata lisakihina. Cloudflare on kasutusele võtnud kaitsereeglid, kuid hoiatab ise, et ainult päringuandmete põhjal koostatud reeglid ei piisa. WAF on seetõttu täiendus, mitte asendus. Lähemalt lehel WAF ja virtuaalne paikamine.
Kindlustage lisaks serveri logid alates 20. oktoobrist. Meediateadete kohaselt täheldati esimest ründekatset juba 17. oktoobril; logid on alus, kui peate hiljem selgitama, kas enne paika midagi juhtus.
Kuidas PHP SOS konkreetselt aitab?
- Olukorra selgitamine: Kontrollime, kas uuendus on lühikese ajaga võimalik või on vaja üleminekut, ning arutame teiega võimalust osa võrgust maha võtta.
- Meetmete seadmine: Kirjutame php.net-i väärtused õigesse kohta, seame cgroupi piirangu ja käivitame kõik tööprotsessid uuesti.
- Funktsiooni test: Vorme, üleslaadimisi ja tellimisprotsesse kontrollime pärast ümberlülitust.
- Paiga juurde viimine: PHP paikamisteenuse kaudu planeerime uuenduse ja võtame üleminekuväärtused pärast kontrollitult tagasi, kus need segavad.
Korduma kippuvad küsimused
Kas ajutine lahendus kaitseb PHP2Shelli eest täielikult?
Ei. php.net nimetab meetmeid selgesõnaliselt üleminekuks, mitte täielikuks kaitseks. Need vähendavad riski, kuni uuendus on paigaldatud. BSI soovitab serverid ilma paigata ajutiselt võrgust maha võtta.
Kas ma saan sätteid määrata .htaccess-i või .user.ini kaudu?
Sätte session.upload_progress.enabled puhul välistab php.net ini_set() ja .user.ini selgesõnaliselt. Ka memory_limit puhul kehtib: väärtus peab olema seatud nii, et rakendus ei saa seda üle kirjutada. See õnnestub php.ini-s, FPM-i poolis php_admin_value abil või Apache'i serveri seadistuses.
Kas veebirakenduste tulemüür (WAF) piisab ajutise lahendusena?
Täiendava kihina võib see aidata. Cloudflare on kasutusele võtnud kaitsereeglid, kuid juhib ise tähelepanu sellele, et ainult päringuandmete põhjal koostatud reeglid ei piisa. WAF ei asenda ei uuendust ega ajutisi meetmeid serveris.
Mida teha, kui mul on ainult jagatud veebimajutus?
Siis asuvad php.ini ja taaskäivitus veebimajutaja juures. Küsige konkreetselt, kas uuendus on paigaldatud või ajutised meetmed seatud ja kas kõik PHP protsessid on uuesti käivitatud.