Failiõigused veebiserveris

Lühidalt: Failiõiguste puhul veebiserveris kehtib üks põhimõte: kasutaja, kelle all PHP töötab, tohib oma koodi lugeda, kuid mitte muuta. Kirjutusõigus on ainult üleslaadimis-, vahemälu- ja tmp-kaustadel ning seal PHP-d ei käivitata. Õigused nagu 777 ei kuulu tootmisserverisse.

Miks failiõigused teevad pärast sissemurdmist vahet

Kui ründajad käivitavad turvaaugu kaudu serveris koodi, töötab see kood PHP protsessi õigustega. Mida see kasutaja tohib, tohib ka ründaja. Just siin otsustatakse, kas sissemurdmisest saab püsiv tagauks.

PHP2Shelliga on see stsenaarium 2026. aasta oktoobris väga konkreetseks muutunud. Turvaaugud CVE-2026-109618 ja CVE-2026-109619 võimaldavad kahjuliku koodi käivitamist ilma sisselogimata. Need on parandatud alates 21.10.2026 versioonides PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Head failiõigused ei takista rünnakut, kuid takistavad, et sissetoodud kood teie rakendust püsivalt ümber kirjutaks.

Paljudes paigaldustes kuulub kogu kood veebiserveri kasutajale, et uuendused käiksid nupuvajutusega. See on mugav, kuid just selline konstellatsioon, mida ründajad otsivad.

Põhimõte: omanik ja töökasutaja lahutada

Mõistlik on jaotus kaheks rolliks. Omanik, näiteks juurutuskasutaja (deploy), omab faile ja paigaldab uuendused. PHP protsess töötab teise kasutaja all ja on gruppi kaudu õigustatud ainult lugema.

Veebiserver ise, näiteks Nginx, vajab PHP-FPM-i korral ainult lugemisjuurdepääsu staatilistele failidele, nagu pildid ja CSS. Selle saate grupi või sihipärase juurdepääsureegli kaudu. Kes haldab mitut veebisaiti, annab igaühele oma töökasutaja; kuidas see poolidega kokku töötab, on kirjas juhendis open_basedir ja isolatsioon veebisaidi kaupa.

Failiõiguste kontroll veebiserveris

Enne kui midagi muudate, tehke endale ülevaade. Järgmised käsud ei muuda midagi.

# Millise kasutaja all PHP protsessid töötavad?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Kõigile kirjutatavad failid ja kaustad
find /var/www -perm -o+w -ls

# Failid, mis kuuluvad veebiserveri kasutajale (näide www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Seadistusfailide õigused
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null

Kõigile kirjutatavad kirjed on peaaegu alati viga. PHP failid, mis kuuluvad töökasutajale, näitavad, et too saab oma koodi muuta. Silma torkavad lisaks üksikud failid, mille omanik või õigused erinevad naaberfailidest. See võib viidata sissetoodud failidele, nagu on kirjeldatud juhendis Veebishellide tuvastamine ja eemaldamine.

Õiguste parandamine samm-sammult

Muutke õigusi alles pärast varukoopiat ja võimaluse korral esmalt testkeskkonnas. Kui on kahtlus sissemurdmise kohta, turvake enne jäljed, sest omanik ja ajatempel on siis tõendid.

SITE=/var/www/seite1
# Omanik: juurutuskasutaja, grupp: töökasutaja
sudo chown -R deploy:seite1 "$SITE"
# Kaustad 750, failid 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Ainult neid kaustu tohib PHP kirjutada (kohandage teed rakendusele)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"

Kontrollige seejärel veebisaiti täielikult: avaleht, sisselogimine, vormid, piltide üleslaadimine, vahemälud. Milliseid kaustu rakendus peab kirjutama, on kirjas tootja süsteeminõuetes tema ametlikul lehel.

PHP käivitamise takistamine kirjutatavates kaustades

Kirjutusõigused on poole vähem ohtlikud, kui seal koodi käivitada ei saa. Lukustage PHP käivitamine üleslaadimis- ja vahemälukaustades veebiserveri tasemel. Apache'i puhul VirtualHost'i seadistuses:

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

Nginxi puhul piisab location-plokist, mis lükkab tagasi päringud PHP failidele nendes kaustades. Reegel kuulub serveri seadistusse, mitte .htaccess-i üleslaadimiskaustas, mida kirjutusõigusega ründaja saaks uuesti muuta.

Lisaks tasub vaadata juurutuskasutaja umask-i, et uusi faile ei looda automaatselt liiga avatuna. Väärtus 027 annab failidele 640 ja kaustadele 750. Oma serverites lasub see vastutus täielikult teil; mis veel juurde kuulub, kirjeldab leht Root-serveri ja vServeri enda turvamine.

Erijuhtumid: hostingupaneelid, jagatud veebimajutus ja juurutused

Kõiki servereid ei saa seadistada õpiku järgi. Hostingupaneelid nagu Plesk või cPanel loovad oma kasutajad ja õigused ning lähtestavad need mõne toimingu korral. Muutke õigusi seal võimaluse korral paneeli funktsioonide kaudu või kontrollige pärast paneeli uuendusi, kas teie seaded kehtivad veel.

Jagatud veebimajutuses on teil enamasti kõige jaoks üks kasutaja. Omaniku ja töökasutaja lahutamine ei ole siis võimalik. Seda olulisemad on napid õigused seadistusfailidele, 777-õiguste puudumine ja PHP käivitamise väljalülitamine üleslaadimiskaustades, kuivõrd veebimajutaja seda lubab.

Kes töötab automaatsete juurutustega, peaks õigused seadma juurutusskriptis endas. Muidu taastab iga uus versioon vana, liiga avatud seisu. Lühike kontroll juurutuse lõpus, näiteks ülaltoodud käsuga kirjutatavate failide jaoks, püüab sellised tagasilöögid usaldusväärselt kinni ja seda saab ilma suure vaevata igasse torusse (pipeline) lisada.

Kuidas PHP SOS konkreetselt aitab?

• Kaardistame kõigi serveri veebisaitide omanikud, õigused ja töökasutajad.
• Määrame õiguste kontseptsiooni, mis sobib teie rakenduse ja uuendustee jaoks.
• Rakendame õigused ja käivituslukud ning testime seejärel veebisaiti täielikult.
• Dokumenteerime kontseptsiooni, et juurutused ja uuendused seda uuesti ei lõdvendaks.

Kuidas see põimub püsivasse kaitsesse, kirjeldab teenus Serveri karastamine PHP veebiserveritele.

Korduma kippuvad küsimused

Allikad

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