Trumpai: PHP failas įkėlimų aplanke yra rimtas įspėjamasis ženklas, nes ten turėtų būti tik paveikslėliai ir dokumentai. Niekada neatidarykite failo naršyklėje, o skaitykite jį kaip tekstą, patikrinkite laiko žymas ir savininką ir ieškokite failo pavadinimo prieigos žurnaluose. Nekenksmingi dažniausiai tik tušti laikikliai, pavyzdžiui, index.php be turinio; viską kita traktuokite kaip galimą įsilaužimą.
Kodėl PHP įkėlimų aplanke nėra ko ieškoti
Įkėlimų aplankai skirti turiniui, kurį įkelia lankytojai ar redaktoriai: paveikslėliams, PDF, vaizdo įrašams. Žiniatinklio serverio naudotojas ten gali rašyti, kitaip įkėlimai neveiktų. Būtent tai daro šiuos aplankus patrauklius užpuolikams. Kas per pažeidžiamumą gali rašyti failus, deda juos ten, kur rašyti leidžiama.
Nauji PHP failai įkėlimų ar talpyklos aplankuose pagal mūsų turimus pranešimus priklauso bendriesiems įspėjamiesiems ženklams po įsilaužimo. PHP2Shell atveju patvirtintų kompromitavimo indikatorių (Indicators of Compromise) nėra; radinys todėl nieko nepasako apie tai, per kokį pažeidžiamumą failas pateko. Kaip saugiai kuriamos įkėlimo funkcijos, aprašo Saugus failų įkėlimas PHP.
Ar toks failas gali pridaryti žalos, lemia žiniatinklio serverio konfigūracija. Jei jis įkėlimų aplanke PHP failus vykdo, kiekvienas ten padėtas failas tampa galimu nuotoliniu valdymu. Jei vykdymas ten užblokuotas, failas lieka svetimkūniu, bet iš pradžių be poveikio. Daugelyje diegimų šis blokavimas niekada nebuvo įrengtas.
Kaip PHP failas patenka į įkėlimų aplanką?
Vertinant padeda žinoti galimus kelius. Kiekvienas veda prie kitų tolesnių klausimų.
| Kelias | Tipinis pagrindas | Tolesnis klausimas |
|---|---|---|
| Nesaugi įkėlimo forma | tikrinama tik galūnė ar naršyklės nurodytas tipas | Kurios formos priima failus? |
| Pažeidžiamumas įskiepyje ar temoje | žinoma silpnybė pasenusiame plėtinyje | Kurie plėtiniai pasenę? |
| Pavogti prisijungimo duomenys | administratoriaus, FTP ar hostingo paskyra | Kokie prisijungimai buvo neseniai? |
| Kodo vykdymas per pažeidžiamumą | pavyzdžiui, interpretatoriuje, kaip galima esant PHP2Shell | Ar PHP tuo laikotarpiu buvo pažeidžiamas? |
| Teisėtas įskiepis | laikikliai, retai talpyklos failai | Ar failas priklauso originaliam paketui? |
Keli keliai gali susidurti. Užpuolikas, per pažeidžiamumą vykdantis kodą, failą gali palikti tik tam, kad vėliau patogiau sugrįžtų.
Radimo vietas išvardyti sistemingai
Prieš vertindami atskirą failą, susidarykite apžvalgą. Komandos tik skaito. Keliai yra WordPress pavyzdžiai; kitose sistemose įkėlimų kelią pritaikykite.
# PHP primenantys failai įkėlimų aplanke su dydžiu, savininku, mtime ir ctime
find /var/www/html/wp-content/uploads -type f \
\( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
-printf '%s Bytes %u m:%T+ c:%C+ %p\n'
# Failo tipą nustatyti pagal turinį, o ne galūnę (krenta į akis paveikslėliai su PHP turiniu)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Kitos sistemos naudoja kitus rašymo aplankus, pavyzdžiui, fileadmin TYPO3, images Joomla ar medijos aplanką po public Shopware 6. Be to, yra programos talpyklos ir laikinieji katalogai. Multisite diegimuose ir kelių svetainių viename serveryje atitinkamai daug įkėlimų aplankų; kiekvienas priklauso paieškai.
Įtartini ir .htaccess bei .user.ini failai įkėlimų aplanke. Su jais galima vėl įjungti PHP vykdymą tame aplanke arba pakeisti konfigūraciją.
PHP failas uploads aplanke: kaip teisingai suprasti radinį
Ne kiekvienas radinys vienodai rimtas. Toliau pateiktas įvertinimas padeda pirmam vertinimui. Jis nepakeičia atidaus tyrimo.
| Radinys | Pirmas įvertinimas |
|---|---|
index.php su nuliais baitų arba tik komentaru |
dažniausiai laikiklis nuo katalogo išvardijimo, palyginti su įskiepiu |
| PHP failas su turiniu mėnesio aplanke | didelis įtarimas |
Dviguba galūnė, pavyzdžiui, bild.jpg.php ar .php.png |
didelis įtarimas, tipiškas maskavimas |
Paveikslėlis, kuriame pagal file yra PHP kodo |
didelis įtarimas, gali būti vykdomas per įtraukimą |
.htaccess ar .user.ini įkėlimų aplanke |
įtarimas, patikrinti konfigūraciją |
| Failas priklauso žiniatinklio serverio naudotojui, ctime po spalio 17 d. | atitinka įsilaužimą per svetainę |
Įtartinus failus skaitykite tik kaip tekstą, pavyzdžiui, su head -c 2000 datei.php ar less. Krenta į akis labai ilgos eilutės, užkoduotos simbolių eilutės ir funkcijų pavadinimai, tokie kaip eval ar base64_decode. Kaip atpažinti užmaskuotą kodą, parodo Užmaskuoto PHP kodo atpažinimas.
Ar failas buvo iškviestas? Žvilgsnis į žurnalą
Svarbiausias klausimas po radinio: ar kas nors failą naudojo? Atsakymas yra žiniatinklio serverio prieigos žurnaluose. Ieškokite failo pavadinimo, taip pat archyvuotuose žurnaluose.
# Įtartino failo kreipiniai dabartiniuose ir supakuotuose žurnaluose (pavadinimas kaip pavyzdys)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null
# Tik sėkmingi kreipiniai su IP adresu ir laiku
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Daug sėkmingų POST užklausų iš kelių adresų rodo aktyvų naudojimą kaip webshell. Radinių nebuvimas automatiškai nereiškia, kad pavojaus nėra, nes žurnalai gali būti pasukti, ištrinti ar nepilni. Jei svetainė veikia už CDN ar tarpinio serverio, kiti protokolai yra ten; bendrinamo hostingo atveju prieigos žurnalus hostingo teikėjas dažniausiai pateikia kliento zonoje. Atkreipkite dėmesį ir į užklausas į kitus naujus failus iš tų pačių adresų, nes jos dažnai veda prie kitų dalių. Saugokite žurnalus nuo spalio 20 d. Kaip išsamiai vertinti žurnalus, aprašyta vadove Žiniatinklio serverio žurnalų vertinimas po atakos.
Jei žurnalas rodo sėkmingus nežinomo PHP failo kreipinius, laikykite, kad įvyko įsilaužimas. Išsaugokite failą ir žurnalus, apribokite prieigą prie serverio ir patikrinkite, ar gali būti paveikti asmens duomenys.
Po vertinimo: teisinga eilės tvarka
- Išsaugoti: nukopijuoti failą su kontroline suma ir laiko žymomis, išsaugoti žurnalus.
- Išsiaiškinti kilmę: patikrinti įkėlimo formas, įskiepius ir laikotarpį prieš radinį.
- Ieškoti kitų dalių: papildomų failų, cron užduočių, naujų administratorių paskyrų.
- Užblokuoti vykdymą: PHP įkėlimų aplanke uždrausti žiniatinklio serverio lygiu, kaip aprašyta straipsnyje PHP vykdymo uždraudimas įkėlimų aplankuose.
- Išvalyti ir pakeisti prieigas: tik tada failą pašalinti ir atnaujinti visus slaptažodžius.
Kaip PHP SOS padeda konkrečiai?
- Įvertinti radinį: failą tikriname jo nevykdydami ir jį klasifikuojame.
- Išsiaiškinti naudojimą: vertiname žurnalus ir atkuriame, kas ir kada failą iškvietė.
- Išvalyti visiškai: su kenkėjiškos programinės įrangos šalinimu ieškome visų dalių, uždarome priežastį ir keičiame prieigas.
- Užkirsti kelią pasikartojimui: užblokuojame PHP vykdymą rašomuose aplankuose ir stebime naujus failus.
Dažni klausimai
Ar kiekvienas PHP failas įkėlimų aplanke pavojingas?
Ne kiekvienas. Kai kurie įskiepiai palieka tuščią index.php, kad aplanko turinys nebūtų išvardytas. Viską kita, ypač failus su turiniu, neįprastu pavadinimu ar dviguba galūne, traktuokite kaip įtartinus atvejus.
Ar įtartiną failą galiu atidaryti naršyklėje?
Ne. Kreipinys per svetainę vykdo kodą. Failą skaitykite tik kaip tekstą serveryje arba kopijoje, pavyzdžiui, su less ar head.
Kaip išsiaiškinti, ar failas buvo naudotas?
Ieškokite failo pavadinimo žiniatinklio serverio prieigos žurnaluose. Užklausos su būsena 200 ir POST metodu rodo, kad failas buvo iškviestas. Susiję IP adresai ir laikai padeda tolesniame tyrime.
Ar pakanka failą ištrinti ir užblokuoti PHP įkėlimų aplanke?
Abu veiksmai reikalingi, bet nepakankami. Papildomai išsiaiškinkite, kaip failas ten pateko, ieškokite kitų dalių ir pakeiskite prisijungimo duomenis. Kitaip užpuolikas sugrįš tuo pačiu keliu.