Trumpai: Nustatant failų teises žiniatinklio serveryje galioja pagrindinis principas: naudotojas, kuriuo veikia PHP, savo kodą gali skaityti, bet ne keisti. Rašymo teises gauna tik įkėlimų, talpyklos ir laikinų failų aplankai, ir ten PHP nevykdomas. Teisės, tokios kaip 777, produkciniame serveryje netinka.
Kodėl failų teisės po įsilaužimo lemia skirtumą
Kai užpuolikai per pažeidžiamumą vykdo kodą serveryje, tas kodas veikia su PHP proceso teisėmis. Ką gali šis naudotojas, gali ir užpuolikas. Būtent čia išsprendžiama, ar įsilaužimas virs nuolatinėmis užpakalinėmis durimis.
Su PHP2Shell šis scenarijus 2026 m. spalį tapo labai konkretus. Pažeidžiamumai CVE-2026-109618 ir CVE-2026-109619 leidžia vykdyti kenkėjišką kodą be prisijungimo. Jie ištaisyti nuo 2026-10-21 PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijose. Geros failų teisės atakos nesustabdo, bet neleidžia įterptam kodui ilgam perrašyti jūsų programos.
Daugelyje instaliacijų visas kodas priklauso žiniatinklio serverio naudotojui, kad atnaujinimai veiktų paspaudus mygtuką. Tai patogu, bet būtent tokios padėties užpuolikai ir ieško.
Pagrindinis principas: atskirkite savininką ir vykdymo naudotoją
Prasminga skirstyti į dvi roles. Savininkas, pavyzdžiui, diegimo (deploy) naudotojas, turi failus ir įdiegia atnaujinimus. PHP procesas veikia kitu naudotoju ir per grupę turi tik skaitymo teisę.
| Sritis | Savininkas : grupė | Failų teisės | Aplankų teisės |
|---|---|---|---|
| Programos kodas | deploy : seite1 | 640 | 750 |
| Konfigūracija su slaptažodžiais | deploy : seite1 | 640 | – |
| Įkėlimai, talpykla, laikini failai | seite1 : seite1 | 640 | 750 |
| Žurnalai | root arba seite1 | 640 | 750 |
Pats žiniatinklio serveris, pavyzdžiui, Nginx, su PHP-FPM reikalauja tik skaitymo prieigos prie statinių failų, tokių kaip paveikslėliai ir CSS. Ją gaunate per grupę arba tikslinę prieigos taisyklę. Kas valdo kelias svetaines, kiekvienai suteikia savą vykdymo naudotoją; kaip tai dera su baseinais, aprašo vadovas open_basedir ir izoliacija kiekvienai svetainei.
Failų teisių žiniatinklio serveryje patikra
Prieš ką nors keisdami susipažinkite su padėtimi. Šios komandos nieko nekeičia.
# Kuriuo naudotoju veikia PHP procesai?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Visiems rašomi failai ir aplankai
find /var/www -perm -o+w -ls
# Žiniatinklio serverio naudotojui priklausantys failai (pavyzdys www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Konfigūracijos failų teisės
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Visiems rašomi įrašai beveik visada yra klaida. PHP failai, priklausantys vykdymo naudotojui, rodo, kad šis gali keisti savo kodą. Be to, krenta į akis atskiri failai, kurių savininkas ar teisės skiriasi nuo kaimyninių. Tai gali rodyti įterptus failus, kaip aprašyta vadove Webshell aptikimas ir šalinimas.
Teisių taisymas žingsnis po žingsnio
Teises keiskite tik po atsarginės kopijos ir pageidautina pirmiausia testinėje aplinkoje. Jei įtariamas įsilaužimas, pirmiausia išsaugokite pėdsakus, nes savininkas ir laiko žymės tuomet yra įrodymai.
SITE=/var/www/seite1
# Savininkas: diegimo naudotojas, grupė: vykdymo naudotojas
sudo chown -R deploy:seite1 "$SITE"
# Aplankai 750, failai 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Tik šiuos aplankus PHP gali rašyti (kelius pritaikykite programai)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Po to pilnai patikrinkite svetainę: pradžios puslapį, prisijungimą, formas, paveikslėlių įkėlimą, talpyklas. Kuriuos aplankus programa privalo rašyti, nurodyta gamintojo sistemos reikalavimuose jo oficialioje svetainėje.
chmod -R 777, norint greitai išspręsti problemą, atveria serverį kiekvienam vietiniam naudotojui ir kiekvienam įterptam procesui. Vietoj to ištaisykite savininką ir grupę.
PHP vykdymo rašomuose aplankuose prevencija
Rašymo teisės perpus pavojingesnės, jei ten kodas negali veikti. Uždrauskite PHP vykdymą įkėlimų ir talpyklos aplankuose žiniatinklio serverio lygiu. Apache VirtualHost konfigūracijoje:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Nginx pakanka location bloko, kuris atmeta užklausas PHP failams šiuose aplankuose. Taisyklė priklauso serverio konfigūracijai, o ne .htaccess įkėlimų aplanke, kurią užpuolikas su rašymo teisėmis galėtų vėl pakeisti.
Papildomai verta pažiūrėti į diegimo naudotojo umask, kad nauji failai automatiškai nebūtų sukuriami per atviri. Reikšmė 027 duoda 640 failams ir 750 aplankams. Savuose serveriuose ši atsakomybė visiškai jūsų; kas dar prie to priklauso, aprašo Root serverio ir vServer apsauga savo jėgomis.
Ypatingi atvejai: hostingo skydeliai, bendrinamas hostingas ir diegimai
Ne kiekvieną serverį galima sukonfigūruoti pagal vadovėlį. Hostingo skydeliai, tokie kaip Plesk ar cPanel, patys sukuria naudotojus ir teises ir kai kuriais veiksmais jas atstato. Teises ten keiskite pageidautina per skydelio funkcijas arba po skydelio atnaujinimų patikrinkite, ar jūsų nustatymai dar galioja.
Bendrinamame hostinge dažniausiai turite vieną naudotoją viskam. Savininko ir vykdymo naudotojo atskyrimas tuomet neįmanomas. Tuo svarbesnės yra kuklios teisės konfigūracijos failams, jokių 777 teisių ir PHP vykdymo išjungimas įkėlimų aplankuose, kiek tai leidžia hostingo teikėjas.
Kas dirba su automatiniais diegimais, teises turėtų nustatyti paties diegimo skripte. Kitaip kiekviena nauja versija atkuria seną, per atvirą būseną. Trumpa patikra diegimo pabaigoje, pavyzdžiui, aukščiau pateikta komanda rašomiems failams, patikimai sustabdo tokius žingsnius atgal ir be didelių pastangų įtraukiama į bet kurį procesą (pipeline).
Kaip PHP SOS padeda konkrečiai?
- Užfiksuojame visų serverio svetainių savininkus, teises ir vykdymo naudotojus.
- Nustatome teisių koncepciją, tinkančią jūsų programai ir atnaujinimo keliui.
- Įgyvendiname teises ir vykdymo draudimus, o po to pilnai išbandome svetainę.
- Koncepciją dokumentuojame, kad diegimai ir atnaujinimai jos vėl nesušvelnintų.
Kaip tai įtraukta į ilgalaikę apsaugą, aprašo paslauga PHP žiniatinklio serverių sutvirtinimas.
Dažni klausimai
Ar 777 teisės kada nors tinka?
Produkciniame serveryje praktiškai niekada. Su 777 bet kuris sistemos naudotojas gali kurti ir keisti failus. Jei programa be 777 neveikia, dažniausiai neteisingai nustatytas savininkas, o ne per mažos teisės.
Kodėl žiniatinklio serveris neturėtų galėti keisti savo failų?
Nes įterptas kodas veikia su žiniatinklio serverio teisėmis. Jei žiniatinklio serveris gali rašyti PHP failus, užpuolikas gali pakeisti esamus skriptus arba įrengti naujas užpakalines duris. Atskyrus savininką ir vykdymo naudotoją, kodas lieka apsaugotas nuo rašymo.
Kaip atnaujinti CMS, jei žiniatinklio serveris negali rašyti?
Atnaujinimai tuomet vykdomi per savininką, pavyzdžiui, su WP-CLI, Composer ar diegimu (deployment), o ne atnaujinimo mygtuku administravimo srityje. Tai kiek sudėtingiau, bet įterptas kodas negali keisti programos failų.
Kokių teisių reikia konfigūracijos failui su duomenų bazės slaptažodžiu?
Kuo mažiau: skaitomas PHP naudotojo, niekieno kito. Įprasta 640 su tinkama grupe arba 400, kai pats PHP naudotojas yra savininkas.