# open_basedir és weboldalankénti elkülönítés

> Az open_basedir helyes beállítása és a weboldalak elválasztása: saját felhasználó, saját PHP-FPM-pool, saját temp-mappák. Nginx mintakonfigurációval.

Forrás: https://phpsos.de/hu/ratgeber/open-basedir/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/ratgeber/disable-functions/) ú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.

```ini
; /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:

```bash
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](https://phpsos.de/hu/ratgeber/dateirechte-webserver/) ú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.

```nginx
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](https://phpsos.de/hu/server/nginx-php-fpm/) oldalon talál. Az újraindítás után ellenőrizze, hogy a poolok valóban elkülönítve futnak-e:

```bash
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.

> **Tipp:**
> 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](https://phpsos.de/hu/branchen/agenturen-white-label/) 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](https://phpsos.de/hu/leistungen/server-haertung/) 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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz (német Szövetségi Információbiztonsági Hivatal)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)