Pravice datotek na spletnem strežniku

Na kratko: Pri pravicah datotek na spletnem strežniku velja eno načelo: uporabnik, pod katerim teče PHP, sme lastno kodo brati, ne pa spreminjati. Pravice pisanja dobijo samo mape za nalaganja, predpomnilnik in tmp, tam pa se PHP ne izvaja. Pravice, kot je 777, na produkcijskem strežniku nimajo kaj iskati.

Zakaj pravice datotek po vdoru naredijo razliko

Ko napadalci prek ranljivosti izvedejo kodo na strežniku, ta koda teče s pravicami procesa PHP. Kar sme ta uporabnik, sme tudi napadalec. Prav tu se odloči, ali iz vdora nastanejo trajna stranska vrata.

S PHP2Shell je ta scenarij oktobra 2026 postal zelo konkreten. Ranljivosti CVE-2026-109618 in CVE-2026-109619 omogočata izvajanje škodljive kode brez prijave. Odpravljeni sta od 21. 10. 2026 v PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Dobre pravice datotek napada ne preprečijo, preprečijo pa, da bi vnesena koda trajno prepisala vašo aplikacijo.

Pri številnih namestitvah vsa koda pripada uporabniku spletnega strežnika, da posodobitve delujejo na pritisk gumba. To je udobno, a prav to je konstelacija, ki jo napadalci iščejo.

Osnovno načelo: ločite lastnika in uporabnika med izvajanjem

Smiselna je delitev na dve vlogi. Lastnik, na primer uporabnik deploya, je lastnik datotek in namešča posodobitve. Proces PHP teče pod drugim uporabnikom in ima prek skupine samo pravico branja.

Sam spletni strežnik, na primer Nginx, pri PHP-FPM potrebuje samo dostop za branje do statičnih datotek, kot so slike in CSS. Dobi ga prek skupine ali ciljnega pravila dostopa. Kdor upravlja več spletnih strani, vsaki dodeli lastnega uporabnika med izvajanjem; kako to sodeluje s pooli, piše v vodniku open_basedir in izolacija po spletnih straneh.

Preverjanje pravic datotek na spletnem strežniku

Preden karkoli spremenite, si ustvarite pregled. Naslednji ukazi nič ne spremenijo.

# Pod katerim uporabnikom tečejo procesi PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Datoteke in mape, v katere lahko piše vsak
find /var/www -perm -o+w -ls

# Datoteke, ki pripadajo uporabniku spletnega strežnika (primer www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Pravice konfiguracijskih datotek
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null

Vnosi, v katere lahko piše vsak, so skoraj vedno napaka. Datoteke PHP, ki pripadajo uporabniku med izvajanjem, kažejo, da lahko ta uporabnik spreminja lastno kodo. Sumljive so tudi posamezne datoteke, katerih lastnik ali pravice odstopajo od sosednjih. To je lahko namig na vnesene datoteke, kot je opisano v vodniku Prepoznavanje in odstranitev webshellov.

Popravljanje pravic: korak za korakom

Pravice spreminjajte samo po varnostnem kopiranju in po možnosti najprej v testnem okolju. Če obstaja sum vdora, najprej zavarujte sledi, saj sta lastnik in časovni žig tedaj dokazno gradivo.

SITE=/var/www/seite1
# Lastnik: uporabnik deploya, skupina: uporabnik med izvajanjem
sudo chown -R deploy:seite1 "$SITE"
# Mape 750, datoteke 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Samo te mape sme PHP pisati (poti prilagodite aplikaciji)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"

Nato spletno stran preverite v celoti: začetna stran, prijava, obrazci, nalaganje slik, predpomnilniki. Katere mape mora aplikacija pisati, piše v sistemskih zahtevah proizvajalca na njegovi uradni strani.

Preprečite izvajanje PHP v mapah, v katere je mogoče pisati

Pravice pisanja so le napol tako nevarne, če tam ni mogoče izvajati kode. Izvajanje PHP v mapah za nalaganje in predpomnilnik blokirajte na ravni spletnega strežnika. Za Apache v konfiguraciji VirtualHost:

<Directory "/var/www/seite1/public/uploads">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>

Za Nginx zadošča blok location, ki zavrne zahteve za datoteke PHP v teh mapah. Pravilo sodi v konfiguracijo strežnika, ne v .htaccess v mapi za nalaganje, ki bi jo lahko napadalec s pravicami pisanja znova spremenil.

Dodatno se splača pogledati umask uporabnika deploya, da se nove datoteke ne ustvarjajo samodejno preveč odprte. Vrednost 027 vodi do 640 za datoteke in 750 za mape. Na lastnih strežnikih ta odgovornost v celoti leži na vas; kaj sodi zraven še, opisuje stran Samostojna zaščita root strežnika in vServerja.

Posebni primeri: upravljalni paneli gostovanja, shared hosting in deploymenti

Vsakega strežnika ni mogoče nastaviti po učbeniku. Upravljalni paneli gostovanja, kot sta Plesk ali cPanel, ustvarijo lastne uporabnike in pravice ter jih pri nekaterih dejanjih ponastavijo. Pravice tam po možnosti spreminjajte prek funkcij panela ali po posodobitvah panela preverite, ali vaše nastavitve še veljajo.

Pri shared hostingu imate običajno samo enega uporabnika za vse. Ločitev lastnika in uporabnika med izvajanjem tedaj ni mogoča. Tem pomembnejše so ozke pravice na konfiguracijskih datotekah, nobenih pravic 777 in izklop izvajanja PHP v mapah za nalaganje, kolikor to ponudnik gostovanja dopušča.

Kdor dela s samodejnimi deploymenti, naj pravice nastavi v samem skriptu deploya. Sicer vsaka nova različica znova vzpostavi staro, preveč odprto stanje. Kratko preverjanje ob koncu deploya, na primer z zgornjim ukazom za datoteke, v katere lahko piše vsak, takšne korake nazaj zanesljivo ujame in ga je mogoče brez velikega napora vgraditi v vsak cevovod.

Kako PHP SOS pomaga konkretno?

• Zajamemo lastnike, pravice in uporabnike med izvajanjem vseh spletnih strani na strežniku.
• Določimo koncept pravic, ki ustreza vaši aplikaciji in vaši poti posodobitev.
• Uvedemo pravice in blokade izvajanja ter nato spletno stran popolnoma preizkusimo.
• Koncept dokumentiramo, da ga deploymenti in posodobitve ne omilijo znova.

Kako je to vključeno v trajno zaščito, opisuje storitev Utrjevanje strežnikov PHP.

Pogosta vprašanja

Viri

• OWASP Cheat Sheet Series
• BSI IT-Grundschutz
• php.net: varnostna obvestila