Röviden: A webszerver fájljogosultságainál egy alapelv érvényes: az a felhasználó, amely alatt a PHP fut, olvashatja a saját kódját, de nem módosíthatja. Írási jogot csak a feltöltési, gyorsítótár- és temp-mappák kapnak, és ott nem hajtanak végre PHP-t. A 777-hez hasonló jogoknak nincs helyük egy éles szerveren.
Miért dönt a fájljogosultság egy behatolás után
Ha a támadók egy résen keresztül kódot futtatnak egy szerveren, ez a kód a PHP-folyamat jogaival fut. Amit ez a felhasználó megtehet, azt megteheti a támadó is. Éppen itt dől el, hogy egy behatolásból tartós hátsó ajtó lesz-e.
A PHP2Shell révén ez a forgatókönyv 2026 októberében nagyon konkréttá vált. A CVE-2026-109618 és CVE-2026-109619 rések bejelentkezés nélküli kártékony kód futtatását teszik lehetővé. 2026. 10. 21. óta javítva vannak a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban. A jó fájljogosultságok nem akadályoznak meg egy támadást, de megakadályozzák, hogy a bejuttatott kód tartósan átírja az alkalmazását.
Sok telepítésben az egész kód a webszerver-felhasználóhoz tartozik, hogy a frissítések egy gombnyomásra működjenek. Ez kényelmes, de éppen az a konstelláció, amelyet a támadók keresnek.
Az alapelv: a tulajdonos és a futtató felhasználó szétválasztása
Célszerű két szerepre osztani. Egy tulajdonos, például egy deploy-felhasználó birtokolja a fájlokat és telepíti a frissítéseket. A PHP-folyamat egy másik felhasználó alatt fut, és csak a csoporton keresztül van olvasási joga.
| Terület | Tulajdonos : csoport | Fájlok jogai | Mappák jogai |
|---|---|---|---|
| Programkód | deploy : seite1 | 640 | 750 |
| Konfiguráció jelszavakkal | deploy : seite1 | 640 | – |
| Feltöltések, gyorsítótár, temp | seite1 : seite1 | 640 | 750 |
| Naplók | root vagy seite1 | 640 | 750 |
Maga a webszerver, például az Nginx, PHP-FPM mellett csak olvasási hozzáférést igényel a statikus fájlokhoz, például a képekhez és a CSS-hez. Ezt a csoporton vagy egy célzott hozzáférési szabályon keresztül kapja meg. Aki több weboldalt üzemeltet, mindegyiknek saját futtató felhasználót ad; hogyan működik ez együtt a poolokkal, azt az open_basedir és weboldalankénti elkülönítés útmutató írja le.
Fájljogosultságok ellenőrzése a webszerveren
Mielőtt bármit módosítana, szerezzen áttekintést. A következő parancsok nem változtatnak semmin.
# Melyik felhasználó alatt futnak a PHP-folyamatok?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Mindenki számára írható fájlok és mappák
find /var/www -perm -o+w -ls
# A webszerver-felhasználóhoz tartozó fájlok (példa: www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# A konfigurációs fájlok jogai
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
A mindenki számára írható bejegyzések szinte mindig hibát jelentenek. A futtató felhasználóhoz tartozó PHP-fájlok azt mutatják, hogy ez módosíthatja a saját kódját. Feltűnőek emellett az egyes fájlok, amelyek tulajdonosa vagy jogai eltérnek a szomszédos fájlokétól. Ez bejuttatott fájlokra utalhat, ahogy azt a Webshellek felismerése és eltávolítása útmutató leírja.
Jogok javítása: lépésről lépésre
A jogokat csak mentés után, lehetőleg előbb egy tesztkörnyezetben módosítsa. Ha behatolás gyanúja áll fenn, előtte mentse a nyomokat, mert a tulajdonos és az időbélyegek ilyenkor bizonyítékok.
SITE=/var/www/seite1
# Tulajdonos: deploy-felhasználó, csoport: futtató felhasználó
sudo chown -R deploy:seite1 "$SITE"
# Mappák 750, fájlok 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Csak ezeket a mappákat írhatja a PHP (az útvonalakat igazítsa az alkalmazáshoz)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Ezután ellenőrizze a weboldalt teljesen: nyitóoldal, bejelentkezés, űrlapok, képfeltöltés, gyorsítótárak. Hogy mely mappákat kell az alkalmazásnak írnia, azt a gyártó rendszerkövetelményei tartalmazzák a hivatalos oldalán.
Egy chmod -R 777, amellyel gyorsan megold egy problémát, megnyitja a szervert minden helyi felhasználó és minden bejuttatott folyamat előtt. Ehelyett a tulajdonost és a csoportot javítsa.
A PHP-végrehajtás megakadályozása írható mappákban
Az írási jogok csak félig olyan veszélyesek, ha ott nem futhat kód. Tiltsa le a PHP végrehajtását a feltöltési és gyorsítótár-mappákban a webszerver szintjén. Apache esetén a VirtualHost-konfigurációban:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Nginxhez elég egy location blokk, amely elutasítja az ezekben a mappákban lévő PHP-fájlokra irányuló kéréseket. A szabály a szerverkonfigurációba tartozik, nem a feltöltési mappában lévő .htaccess-be, amelyet egy írási joggal rendelkező támadó ismét megváltoztathatna.
Kiegészítésként érdemes megnézni a deploy-felhasználó umask értékét, hogy az új fájlok ne jöjjenek létre automatikusan túl nyitottan. A 027 érték a fájloknál 640-et, a mappáknál 750-et eredményez. Saját szervereken ez a felelősség teljes egészében Önt terheli; hogy mi tartozik még ide, azt a Root szerver és vServer saját védelme írja le.
Különleges esetek: tárhelypanelek, megosztott tárhely és deploymentek
Nem minden szerver állítható be tankönyv szerint. Az olyan tárhelypanelek, mint a Plesk vagy a cPanel, saját felhasználókat és jogokat hoznak létre, és egyes műveleteknél visszaállítják őket. A jogokat ott lehetőleg a panel funkcióin keresztül módosítsa, vagy panelfrissítések után ellenőrizze, hogy a beállításai még érvényesek-e.
Megosztott tárhelyen többnyire csak egy felhasználója van mindenre. A tulajdonos és a futtató felhasználó szétválasztása ekkor nem lehetséges. Annál fontosabbak a konfigurációs fájlok szűk jogai, a 777-es jogok mellőzése és a PHP-végrehajtás kikapcsolása a feltöltési mappákban, amennyiben a tárhelyszolgáltató ezt megengedi.
Aki automatikus deploymentekkel dolgozik, a jogokat magában a deployment-szkriptben állítsa be. Különben minden új verzió visszaállítja a régi, túl nyitott állapotot. A deployment végén egy rövid ellenőrzés, például az írható fájlokra vonatkozó fenti paranccsal, megbízhatóan elfogja az ilyen visszalépéseket, és nagy ráfordítás nélkül beépíthető bármely pipeline-ba.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a szerver összes weboldalának tulajdonosát, jogait és futtató felhasználóját.
- Meghatározunk egy jogosultsági koncepciót, amely illeszkedik az Ön alkalmazásához és frissítési útjához.
- Bevezetjük a jogokat és a végrehajtási tiltásokat, majd teljesen teszteljük a weboldalt.
- Dokumentáljuk a koncepciót, hogy a deploymentek és a frissítések ne lazítsák meg újra.
Hogyan ágyazódik ez be egy tartós védelembe, azt a Szerver-keményítés PHP-webszerverekhez szolgáltatás írja le.
Gyakori kérdések
Jó valaha a 777-es jog?
Éles szerveren gyakorlatilag soha. A 777-tel a rendszer minden felhasználója létrehozhat és módosíthat fájlokat. Ha egy alkalmazás 777 nélkül nem fut, többnyire a tulajdonos van rosszul beállítva, nem a jog túl szűk.
Miért ne módosíthassa a webszerver a saját fájljait?
Mert a bejuttatott kód a webszerver jogaival fut. Ha a webszerver írhat PHP-fájlokat, a támadó meglévő szkripteket manipulálhat vagy új hátsó ajtókat hozhat létre. Ha a tulajdonost és a futtató felhasználót elválasztja egymástól, a kód írásvédett marad.
Hogyan frissítsek egy CMS-t, ha a webszerver nem írhat?
A frissítések ilyenkor a tulajdonoson keresztül futnak, például WP-CLI-vel, Composerrel vagy deploymenttel, nem az admin felület frissítés gombjával. Ez kicsit körülményesebb, de a bejuttatott kód így nem tud programfájlokat módosítani.
Milyen jogok kellenek az adatbázisjelszót tartalmazó konfigurációs fájlhoz?
Minél kevesebb: olvasható a PHP-felhasználónak, senki másnak. Szokásos a 640 megfelelő csoporttal, vagy a 400, ha a PHP-felhasználó maga a tulajdonos.