Failu tiesības tīmekļa serverī

Īsi: failu tiesībām tīmekļa serverī ir viens pamatprincips: lietotājs, ar kuru darbojas PHP, drīkst savu kodu lasīt, bet ne mainīt. Rakstīšanas tiesības saņem tikai augšupielāžu, kešatmiņas un pagaidu mapes, un tur PHP netiek izpildīts. Tiesībām, piemēram, 777, produkcijas serverī nav vietas.

Kāpēc failu tiesības pēc ielaušanās ir izšķirošas

Ja uzbrucēji caur ievainojamību izpilda kodu serverī, šis kods darbojas ar PHP procesa tiesībām. Ko drīkst šis lietotājs, to drīkst arī uzbrucējs. Tieši šeit izšķiras, vai no ielaušanās kļūst pastāvīga slēptā piekļuve.

Ar PHP2Shell šis scenārijs 2026. gada oktobrī ir kļuvis ļoti konkrēts. Ievainojamības CVE-2026-109618 un CVE-2026-109619 ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās. Tās ir izlabotas kopš 21.10.2026 versijās PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Labas failu tiesības uzbrukumu nepasargā, bet novērš, ka ievadīts kods pastāvīgi pārraksta jūsu lietojumprogrammu.

Daudzās instalācijās viss kods pieder tīmekļa servera lietotājam, lai atjauninājumi darbotos ar pogas nospiedienu. Tas ir ērti, bet tieši tā ir konstelācija, ko uzbrucēji meklē.

Pamatprincips: nodalīt īpašnieku un izpildes lietotāju

Lietderīgi ir sadalījums divās lomās. Īpašnieks, piemēram, izvietošanas (deploy) lietotājs, ir failu īpašnieks un uzstāda atjauninājumus. PHP process darbojas zem cita lietotāja, un tam ir tiesības tikai lasīt caur grupu.

Pats tīmekļa serveris, piemēram, Nginx, ar PHP-FPM statiskiem failiem, piemēram, attēliem un CSS, vajag tikai lasīšanas piekļuvi. To iegūstat caur grupu vai mērķtiecīgu piekļuves noteikumu. Kas darbina vairākas vietnes, katrai piešķir savu izpildes lietotāju; kā tas sader ar pūliem, aprakstīts ceļvedī open_basedir un izolācija katrai vietnei.

Failu tiesību pārbaude tīmekļa serverī

Pirms ko mainat, gūstiet pārskatu. Turpmākās komandas neko nemaina.

# Zem kura lietotāja darbojas PHP procesi?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Visiem rakstāmi faili un mapes
find /var/www -perm -o+w -ls

# Faili, kas pieder tīmekļa servera lietotājam (piemērs www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Konfigurācijas failu tiesības
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null

Visiem rakstāmi ieraksti gandrīz vienmēr ir kļūda. PHP faili, kas pieder izpildes lietotājam, rāda, ka tas var mainīt savu kodu. Uzkrītoši ir arī atsevišķi faili, kuru īpašnieks vai tiesības atšķiras no kaimiņu failiem. Tā var būt norāde uz ievadītiem failiem, kā aprakstīts ceļvedī Webshell atklāšana un noņemšana.

Tiesību labošana: solis pa solim

Tiesības mainiet tikai pēc dublēšanas un, ja iespējams, vispirms testa vidē. Ja ir aizdomas par ielaušanos, iepriekš saglabājiet pēdas, jo īpašnieks un laika zīmogi tad ir pierādījumi.

SITE=/var/www/seite1
# Īpašnieks: deploy lietotājs, grupa: izpildes lietotājs
sudo chown -R deploy:seite1 "$SITE"
# Mapes 750, faili 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Tikai šīs mapes PHP drīkst rakstīt (ceļus pielāgojiet lietojumprogrammai)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"

Pēc tam pārbaudiet vietni pilnībā: sākumlapu, pieteikšanos, veidlapas, attēlu augšupielādi, kešatmiņas. Kurās mapēs lietojumprogrammai jārakstā, norādīts ražotāja sistēmas prasībās tā oficiālajā vietnē.

PHP izpildes novēršana rakstāmās mapēs

Rakstīšanas tiesības ir uz pusi mazāk bīstamas, ja tur nevar darboties kods. Bloķējiet PHP izpildi augšupielāžu un kešatmiņas mapēs tīmekļa servera līmenī. Apache VirtualHost konfigurācijā:

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

Nginx pietiek ar location bloku, kas atsaka pieprasījumus uz PHP failiem šajās mapēs. Noteikums jāliek servera konfigurācijā, nevis .htaccess augšupielāžu mapē, ko uzbrucējs ar rakstīšanas tiesībām varētu atkal mainīt.

Papildus ir vērts paskatīties uz izvietošanas lietotāja umask, lai jauni faili automātiski netiktu veidoti pārāk atvērti. Vērtība 027 dod 640 failiem un 750 mapēm. Savos serveros šī atbildība pilnībā ir jums; kas vēl pie tā pieder, apraksta raksts Root serveru un vServer pašu nostiprināšana.

Īpaši gadījumi: hostinga paneļi, Shared Hosting un izvietošana

Ne katru serveri var iestatīt pēc mācību grāmatas. Hostinga paneļi, piemēram, Plesk vai cPanel, izveido savus lietotājus un tiesības un dažās darbībās tās atiestata. Tiesības tur mainiet pēc iespējas ar paneļa funkcijām vai pēc paneļa atjauninājumiem pārbaudiet, vai jūsu iestatījumi vēl ir spēkā.

Shared Hosting jums parasti ir tikai viens lietotājs visam. Īpašnieka un izpildes lietotāja nodalīšana tad nav iespējama. Jo svarīgākas ir šauras tiesības konfigurācijas failiem, nekādas 777 tiesības un PHP izpildes izslēgšana augšupielāžu mapēs, ciktāl hostinga sniedzējs to atļauj.

Kas strādā ar automātisku izvietošanu, tiesības jāiestata pašā izvietošanas skriptā. Citādi katra jauna versija atjauno veco, pārāk atvērto stāvokli. Īsa pārbaude izvietošanas beigās, piemēram, ar iepriekš minēto komandu rakstāmiem failiem, šādus atkāpienus uzticami noķer, un to var bez lielām pūlēm iebūvēt jebkurā konveijerā.

Kā PHP SOS palīdz konkrēti?

• Apzinām visu serverī esošo vietņu īpašniekus, tiesības un izpildes lietotājus.
• Nosakām tiesību koncepciju, kas atbilst jūsu lietojumprogrammai un atjaunināšanas ceļam.
• Ieviešam tiesības un izpildes bloķēšanu un pēc tam pilnībā pārbaudām vietni.
• Koncepciju dokumentējam, lai izvietošana un atjauninājumi to nesamazinātu.

Kā tas iekļaujas ilgtermiņa aizsardzībā, apraksta pakalpojums Servera nostiprināšana PHP tīmekļa serveriem.

Biežāk uzdotie jautājumi

Avoti

• OWASP Cheat Sheet Series
• BSI IT-Grundschutz
• php.net: drošības ziņojumi