Īsi sakot: Daudzi PHP2Shell padomi, kas pašlaik cirkulē forumos un sociālajos tīklos, neaizsargā vai pat kaitē: bloķēt pieprasījumus ar sesijas sīkdatni, slēpt kļūdu ziņojumus, iestatījumus iestatīt ar .user.ini vai atjaunināt tikai CMS. php.net ir viennozīmīgs: pilnīgu pagaidu pasākumu nav, PHP atjauninājums ar visu procesu pārstartēšanu ir vienīgais drošais ceļš.
Kāpēc nepareizi padomi šajā situācijā ir bīstami
Kritiskas ievainojamības gadījumā ar lielu uzmanību rodas tirgus ātriem risinājumiem. Padomi tiek dalīti, saīsināti un nodoti tālāk, bieži bez sākotnējā avota ierobežojumiem. PHP2Shell gadījumā turklāt saskaņā ar ziņojumiem detaļas kļuva zināmas jau pirms oficiālā termiņa, un pirmajās dienās situācija bija nepārskatāma.
Nepareizs padoms kaitē divkārt. Tas atstāj ievainojamību atvērtu un rada sajūtu, ka kaut kas ir darīts. Tieši šī sajūta noved pie tā, ka īstais atjauninājums paliek nepaveikts. Daži padomi turklāt paralizē paša vietni.
Deviņi padomi faktu pārbaudē
Šī tabula apkopo to, ko pēdējās dienās bieži lasījām, un pretstata tam primāro avotu apgalvojumus.
| Cirkulējošais padoms | Kāpēc tas nav noturīgs | Kas ir spēkā tā vietā |
|---|---|---|
Bloķēt visus pieprasījumus ar PHPSESSID |
Speciālisti to tieši noraida; paralizē pieteikšanos un grozus | Atjaunināt PHP |
session.upload_progress.enabled=0 pietiek |
Saskaņā ar speciālistu ziņojumiem neaizver abas ievainojamības | Saprātīgs pagaidu pasākums, atjauninājums paliek pienākums |
Iestatīt vērtības ar ini_set() vai .user.ini |
php.net to tieši neiesaka | Servera pusē php.ini, FPM pūlā vai servera konfigurācijā |
| Slēpt kļūdu ziņojumus | Saskaņā ar php.net error_reporting, display_errors vai @ nepalīdz |
Atjauninājums; kļūdu izvadi tomēr nerādīt publiski |
Ierobežot atmiņu ar RLIMIT_AS vai RLIMIT_DATA |
php.net brīdina, ka tieši tas var izraisīt ievainojamo situāciju | Ierobežojums caur konteineru vai cgroup |
| Atjaunināt WordPress vai spraudņus | Ievainojamība ir PHP interpretatorā, nevis CMS | Atjaunināt PHP izpildes vidi |
| Cloudflare vai cita WAF pietiek | Aizsardzība tikai satiksmei caur pakalpojumu; tieši sasniedzami serveri paliek atvērti | WAF kā papildu slānis, nevis aizvietotājs |
| Pakalpojumu pārlādēt, nevis pārstartēt | Saskaņā ar Red Hat reload nepietiek, esošie worker var saglabāt veco stāvokli | Pilnībā pārstartēt visus worker |
| Ielāpots nozīmē tīrs | Ielāps nenoņem iepriekš ievadītu ļaunprātīgu programmatūru | Saglabāt žurnālus no 20.10. un pārbaudīt pēdas |
Trīs biežākie maldi sīkāk
Sīkdatņu aizliegums
Padoms noraidīt visus pieprasījumus ar sesijas sīkdatni PHPSESSID izklausās tehniski un apņēmīgi. Speciālisti to tieši noraida. Praksē tas salauž visu, kam vajadzīga sesija: klientu kontus, grozus, administrēšanas sadaļas, veidlapas ar aizsardzību pret viltošanu. Aizsardzība pret ievainojamību tas nav.
Vienīgais iestatījums, kas visu atrisina
session.upload_progress.enabled=0 ir php.net ieteikumos, un pret CVE-2026-115560 tas ir minētais risinājums. Dažos rakstos no tā kļuva “PHP2Shell izslēgta”. Saskaņā ar speciālistu ziņojumiem šis iestatījums vien neaizver abas ievainojamības. Arī memory_limit=-1 saskaņā ar php.net novērš tikai kontrolējamo izraisītāju; atmiņas kļūda dziļākā līmenī joprojām var sasniegt ievainojamo ceļu. PHP 8.5 fatal_error_backtraces=0 saskaņā ar php.net bloķē tikai apstiprināto ceļu caur backtraces.
Kā iestatījumu tomēr iestatīt pareizi un pastāvīgi, apraksta raksts session.upload_progress izslēgšana. Pilns pagaidu pasākumu saraksts atrodams sadaļā Tūlītēji pasākumi bez ielāpa.
Vairogs priekšā
Cloudflare saskaņā ar saviem datiem no 21. oktobra ir aktivizējis aizsardzības noteikumus, arī klientiem bezmaksas tarifā. Pats Cloudflare tomēr norāda uz ierobežojumiem: aizsardzība darbojas tikai satiksmei, kas iet caur Cloudflare. Ja izcelsmes serveris ir sasniedzams tieši, tā tiek apieta. Turklāt Cloudflare papildus pārbauda servera atbildi, jo pieprasījums vien ne vienmēr ir pietiekams. Kāpēc WAF atjauninājumu neaizstāj, izskaidro raksts WAF vai atjauninājums.
Padoms ar risku: filtrēt augšupielādes pieprasījumus pie malas
Ne katrs neērts padoms ir nepareizs. Speciālisti kā pagaidu, neoficiālu pasākumu iesaka bloķēt multipart/form-data pieprasījumus ārpus īstajiem augšupielādes ceļiem starpniekserverī vai WAF. Tas var samazināt uzbrukuma virsmu, taču salauž veidlapas un augšupielādes, ja atļauto ceļu saraksts ir nepilnīgs.
Kas šo ceļu iet, tam to iepriekš vajadzētu pārbaudīt testa vidē, saskaņot ar nozaru nodaļām un dokumentēt kā īslaicīgu pasākumu. Atjauninājuma aizstājējs tas arī nav.
Daudzi WAF risinājumi šim nolūkam piedāvā novērošanas režīmu, kurā noteikumi vispirms tikai žurnalē, nevis bloķē. Ļaujiet jaunam noteikumam dažas dienas darboties šādi un izvērtējiet, kuri leģitīmi pieprasījumi tiktu skarti. Tikai pēc tam pārslēdziet uz bloķēšanu. Tā izvairīsieties no tā, ka pieteikšanās veidlapas, klientu portāli vai attēlu augšupielāde veikalā nemanīti izkrīt.
Kā pārbaudīt padomu, pirms to īstenojat
Četri jautājumi nošķir lietojamus padomus no bīstamiem:
- Avots: Vai ieteikums nāk no php.net, jūsu distributīva, BSI vai ar vārdu nosaukta speciālista?
- Apgalvojums: Vai pasākums tiek aprakstīts kā pāreja vai kā risinājums? PHP2Shell gadījumā risinājums ir tikai atjauninājums.
- Blakusefekts: Kas salūzt, kad pasākums iedarbojas? Padoms bez norādes uz blakusefektiem ir nepilnīgs.
- Īstenošanas vieta: Vai iestatījums tiek iestatīts servera pusē un nepārrakstāmi, ar sekojošu visu worker pārstartēšanu?
Fiksējiet, kurus pagaidu pasākumus esat kad iestatījuši. Tā varat tos vēlāk mērķtiecīgi pārbaudīt un atpazīt, vai šķietama aizsardzība nav aizkavējusi īsto atjauninājumu.
Kā PHP SOS palīdz konkrēti?
- Mēs pārbaudām pasākumus, kas pie jums jau ir īstenoti, un nošķiram iedarbīgos no neiedarbīgajiem.
- Mēs ieviešam PHP atjauninājumu, pārstartējam visus procesus un apliecinām stāvokli.
- Kur atjauninājums vēl nav iespējams, mēs pagaidu pasākumus pēc php.net ieviešam servera pusē un dokumentēti.
- Ar WAF un virtuālo ielāpošanu mēs papildinām aizsardzību pie malas, neaizstājot atjauninājumu.
Biežāk uzdotie jautājumi
Vai palīdz bloķēt pieprasījumus ar PHPSESSID?
Nē. Speciālisti šo cirkulējošo padomu tieši noraida. Tas paralizē pieteikšanos, grozus un veidlapas, neaizverot ievainojamību interpretatorā.
Vai pret PHP2Shell pietiek ar session.upload_progress.enabled=0?
Nē. Iestatījums ir viens no vairākiem pagaidu pasākumiem un saskaņā ar speciālistu ziņojumiem neaizver abas ievainojamības. Tas ir saprātīgs, bet PHP atjauninājumu neaizstāj.
Vai palīdz display_errors izslēgšana?
PHP2Shell gadījumā nē. php.net norāda, ka diagnostikas slēpšana ar error_reporting, display_errors vai @ operatoru nepalīdz. Produkcijā display_errors citu iemeslu dēļ tomēr jābūt izslēgtam.
Pēc kā atpazīt nopietnu padomu?
Nopietns padoms min savu avotu, apraksta ierobežojumus un pagaidu pasākumus nosauc par tādiem. Kas sola, ka viens iestatījums atjauninājumu padara lieku, PHP2Shell gadījumā maldās.