Röviden: Az open_basedir korlátozza azokat a könyvtárakat, amelyekhez a PHP hozzáférhet. Önmagában ez csak egy további korlát. Hatékony weboldalankénti elkülönítés csak az együttműködésükből születik: saját rendszerfelhasználó, saját PHP-FPM-pool, saját temp-mappa és saját adatbázis-hozzáférések. Ekkor egy weboldal feltörése erre a weboldalra korlátozott marad.
Miért dönt az elkülönítés a kárról a PHP2Shell után
Sok szerveren több weboldal fut egymás mellett: a céges oldal, egy webshop, egy régi kampányoldal, ügynökségeknél gyakran több tucat ügyfélprojekt. Gyakran egy rendszerfelhasználón és egy PHP-folyamaton osztoznak. Ha az egyiket feltörik, az összes többi nyitva áll.
A PHP2Shell kézzelfoghatóvá teszi ezt a kockázatot. 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é, a CMS-től függetlenül. Médiabeszámolók szerint már 2026. 10. 17-én volt egy első támadási kísérlet, a javítások 10. 21-én követték. A megoldás a frissítés. Hogy az előtte lévő időben végrehajtott támadás egy vagy tíz weboldalt érint-e, azt azonban az elkülönítés dönti el.
A második résnél különösen egy további gondolat jön még: a PHP-projekt szerint egy kérés belső állapota megmaradhat egy workerben, és egy későbbi, ugyanabban a workerben futó kérés felhasználhatja. A weboldalankénti külön poolok gondoskodnak arról, hogy a weboldalak egyébként sem osztoznak workereken.
Mit tud az open_basedir
Az open_basedir segítségével könyvtárak listáját adja meg. A PHP fájlfüggvényei, például a fopen, az include vagy a file_get_contents, ezután megtagadják a hozzáférést mindenhez, ami ezen a listán kívül van. Egy bejuttatott szkript így nem olvashatja el egyszerűen a szomszédos weboldal konfigurációs fájljait.
A határok fontosak: az ellenőrzés a PHP-n belül történik. A PHP-n kívül indított programokra nem vonatkozik, és az értelmezőben lévő hibák megkerülhetik. Ezért az open_basedir mindig a letiltott rendszerfüggvényekkel együtt tartozik, ahogy azt a A PHP disable_functions helyes használata útmutató leírja, és mindenekelőtt az operációs rendszer szintjén megvalósított elválasztással.
Weboldalankénti elkülönítés négy rétegben
Egy terhelhető elválasztás több rétegre épül. Mindegyik felfogja azt, amit az előző nem tud.
| Réteg | Intézkedés | Hatás |
|---|---|---|
| Operációs rendszer | weboldalankénti saját rendszerfelhasználó | más weboldalak fájljai nem olvashatók |
| PHP-folyamatok | saját PHP-FPM-pool saját sockettel | nincs közös worker, saját beállítások |
| PHP-konfiguráció | open_basedir, saját tmp- és session-mappa |
további korlát, nincsenek közös temp-fájlok |
| Adatok | saját adatbázis-felhasználó, csak a saját adatbázishoz rendelt jogokkal | nincs hozzáférés idegen ügyféladatokhoz |
Magas védelmi igénynél, például fizetési folyamatot kezelő webshopoknál vagy egészségügyi adatokat kezelő portáloknál konténerek vagy külön szerverek is hozzájönnek.
Az open_basedir beállítása a PHP-FPM-poolban
Az alábbi példa egy weboldal poolját mutatja seite1 saját felhasználóval. Az útvonalakat és a verziószámot igazítsa a rendszeréhez.
; /etc/php/8.3/fpm/pool.d/seite1.conf
[seite1]
user = seite1
group = seite1
listen = /run/php/seite1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = ondemand
pm.max_children = 10
php_admin_value[open_basedir] = /var/www/seite1/:/var/www/seite1-tmp/
php_admin_value[upload_tmp_dir] = /var/www/seite1-tmp/
php_admin_value[sys_temp_dir] = /var/www/seite1-tmp/
php_admin_value[session.save_path] = /var/www/seite1-tmp/sessions
php_admin_value[error_log] = /var/log/php/seite1.error.log
php_admin_flag[session.upload_progress.enabled] = off
Az utolsó sor a php.net PHP2Shell elleni átmeneti intézkedését is rögtön beállítja. Csak a poolból, a php.ini-ből vagy a szerverkonfigurációból hat, ini_set()-tel vagy .user.ini-vel nem. A mappákat megfelelő jogokkal hozza létre:
sudo useradd --system --home /var/www/seite1 --shell /usr/sbin/nologin seite1
sudo mkdir -p /var/www/seite1-tmp/sessions
sudo chown -R seite1:seite1 /var/www/seite1-tmp
sudo chmod 700 /var/www/seite1-tmp
Hogyan nézzenek ki a jogok magában a webkönyvtárban, azt a Fájljogosultságok a webszerveren útmutató írja le.
A webszerver bekötése és az eredmény ellenőrzése
Az Nginxben minden weboldal a saját socketjére hivatkozik. Így egyetlen kérés sem kerül egy másik weboldal poolába.
server {
server_name seite1.example;
root /var/www/seite1/public;
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/seite1.sock;
}
}
Erről a kombinációról további tudnivalókat a Az Nginx és a PHP-FPM biztonságos beállítása oldalon talál. Az újraindítás után ellenőrizze, hogy a poolok valóban elkülönítve futnak-e:
sudo systemctl restart php8.3-fpm
# Minden pool a saját felhasználója alatt fusson
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"
Ezután tesztelje a weboldal összes funkcióját: feltöltések, képfeldolgozás, gyorsítótárak, ütemezett feladatok. A hibanaplóban az open_basedir restriction megjegyzéssel ellátott hibaüzenetek megmutatják, melyik útvonal hiányzik még. Csak olyan útvonalakat vegyen fel, amelyekre az alkalmazásnak valóban szüksége van, és soha ne a teljes fájlrendszert.
A sok ügyfélweboldallal rendelkező ügynökségek a pool-konfigurációt sablonként gondozzák. Így minden új weboldal automatikusan megkapja az elválasztást, ahelyett hogy utólag kellene pótolni. Az erre az esetre vonatkozó háttérinformációk a Biztonsági partner ügynökségeknek oldalon vannak.
Tipikus buktatók az átállásnál
Az átállás külön poolokra tervezhető, de van néhány visszatérő csapdája. A leggyakoribb a közösen használt könyvtárakat érinti: ha például egy keretrendszer vagy egy betűtípusokat tartalmazó mappa a weboldal könyvtárán kívül van, ezt az útvonalat olvasásra fel kell venni az open_basedirbe. Jobb, ha az ilyen függőségeket magába a projektbe hozza.
A második csapda a munkamenetek. Ha a tárolási hely megváltozik, minden látogató egyszer kijelentkezik, és a folyamatban lévő kosarak elvesznek. Ezért az átállást tervezze egy nyugodt időablakba, és belsőleg jelentse be.
Harmadszor, az ütemezett feladatok gyakran a parancssoron keresztül futnak, tehát a weboldaltól eltérő felhasználó alatt. Ellenőrizze a cron-feladatokat és a várakozási sorokat, és futtassa őket az új weboldal-felhasználó alatt, különben rossz tulajdonosú fájlok keletkeznek, amelyeket a PHP később nem módosíthat.
Végül minden poolnak saját korlátokkal kell rendelkeznie a folyamatokra és a memóriára. Egy terhelés alá kerülő vagy megtámadott weboldal így nem tudja térdre kényszeríteni a többit.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük, mely weboldalak osztoznak ma felhasználókon, folyamatokon és adatbázisokon.
- Weboldalanként saját felhasználókat, poolokat, temp-mappákat és adatbázis-hozzáféréseket állítunk be, az alkalmazások módosítása nélkül.
- Az átállás után minden weboldalt tesztelünk, és célzottan javítjuk a hiányzó útvonalakat.
- Az elkülönítést sablonként dokumentáljuk a jövőbeli projektekhez.
Hogyan illeszkedik ez egy átfogó koncepcióba, azt a Szerver-keményítés PHP-webszerverekhez szolgáltatás írja le.
Gyakori kérdések
Elég az open_basedir a weboldalak elválasztásához?
Nem. Az open_basedir a PHP-n belüli további korlát, nem kemény elválasztás. Az elkülönítés csak weboldalankénti saját rendszerfelhasználókkal és poolokkal válik megbízhatóvá, magasabb védelmi igénynél konténerekkel vagy külön szerverekkel.
Miért nem működnek a feltöltések az open_basedir beállítása után?
Többnyire az ideiglenes fájlok mappája hiányzik a listáról. Hozzon létre minden weboldalhoz saját tmp-mappát, vegye fel az open_basedirbe, és állítsa az upload_tmp_dir és a sys_temp_dir értékét erre a mappára.
Feloldhatja az alkalmazás saját maga az open_basedirt?
Egy alkalmazás a beállítást futásidőben csak tovább szűkítheti, lazítani nem tudja. Az open_basedirt ennek ellenére a poolban php_admin_value-val állítsa be, hogy az érték egyértelműen rögzített legyen.
Megosztott tárhelyen is lehetséges az elkülönítés?
Ez a tárhelyszolgáltatótól függ. Sok ajánlat saját felhasználókkal és PHP-folyamatokkal választja el az ügyfeleket. Kérdezzen rá, hogyan valósul meg az elválasztás, különösen ha több weboldala van egy csomagban.