open_basedir a izolace jednotlivých webů

Stručně: open_basedir omezuje adresáře, k nimž smí PHP přistupovat. Samo o sobě je to jen dodatečná zábrana. Účinná izolace jednotlivých webů vzniká až souhrou: samostatný systémový uživatel, samostatný pool PHP-FPM, samostatná složka tmp a samostatné přístupy k databázi. Průnik do jednoho webu pak zůstane omezen na tento web.

Proč o škodě po PHP2Shell rozhoduje izolace

Na mnoha serverech běží vedle sebe několik webů: firemní stránky, e-shop, stará kampaňová stránka, u agentur často desítky projektů zákazníků. Často sdílejí jednoho systémového uživatele a jeden proces PHP. Pokud je jeden z nich kompromitován, ostatní jsou odkryté.

PHP2Shell toto riziko zviditelňuje. Zranitelnosti CVE-2026-109618 a CVE-2026-109619 umožňují spuštění škodlivého kódu bez přihlášení, nezávisle na CMS. Podle zpráv médií byl první pokus o útok už 17. 10. 2026, záplaty následovaly 21. 10. Řešením je aktualizace. Zda ale útok v době před ní zasáhne jeden web, nebo deset, rozhoduje izolace.

U druhé zranitelnosti přistupuje další úvaha: podle projektu PHP může vnitřní stav požadavku v jednom workeru přetrvat a být využit pozdějším požadavkem ve stejném workeru. Oddělené pooly pro každý web zajistí, že si weby žádné workery nesdílejí.

Co open_basedir dokáže

Pomocí open_basedir stanovíte seznam adresářů. Souborové funkce PHP jako fopen, include nebo file_get_contents pak odepřou přístup ke všemu mimo tento seznam. Podstrčený skript tak nemůže bez dalšího číst konfigurační soubory sousedního webu.

Hranice jsou důležité: kontrola probíhá uvnitř PHP. Programy spuštěné mimo PHP jí nepodléhají a chyby v interpretu ji mohou obejít. open_basedir proto vždy patří spolu se zakázanými systémovými funkcemi, jak popisuje příručka Jak správně nasadit disable_functions, a především s oddělením na úrovni operačního systému.

Izolace jednotlivých webů ve čtyřech vrstvách

Spolehlivé oddělení se opírá o několik vrstev. Každá zachytí to, co předchozí nezvládne.

Při vysokých nárocích na ochranu, například u e-shopů s platebním stykem nebo portálů se zdravotními údaji, přistupují kontejnery nebo oddělené servery.

Konfigurace open_basedir v poolu PHP-FPM

Následující příklad ukazuje pool pro web se samostatným uživatelem seite1. Cesty a číslo verze přizpůsobte svému systému.

; /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

Poslední řádek rovnou nastavuje přechodné opatření php.net k PHP2Shell. Působí jen z poolu, php.ini nebo konfigurace serveru, nikoli přes ini_set() nebo .user.ini. Složky založíte s odpovídajícími právy:

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

Jak by měla vypadat práva ve vlastním webovém adresáři, popisuje příručka Práva k souborům na webovém serveru.

Napojení webového serveru a kontrola výsledku

V Nginx odkazuje každý web na svůj vlastní socket. Žádný požadavek tak neskončí v poolu jiného webu.

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;
    }
}

Další pokyny k této kombinaci najdete v článku Zabezpečení Nginx s PHP-FPM. Po restartu ověřte, zda pooly skutečně běží odděleně:

sudo systemctl restart php8.3-fpm
# Každý pool by měl běžet pod vlastním uživatelem
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"

Poté otestujte všechny funkce webu: uploady, zpracování obrázků, cache, plánované úlohy. Chybová hlášení s upozorněním na open_basedir restriction v chybovém logu ukazují, která cesta ještě chybí. Doplňte jen cesty, které aplikace skutečně potřebuje, a nikdy ne celý souborový systém.

Typická úskalí při přechodu

Přechod na oddělené pooly je plánovatelný, má ale několik opakujících se pastí. Nejčastější se týká společně používaných knihoven: pokud například framework nebo složka s písmy leží mimo adresář webu, musí být tato cesta zahrnuta do open_basedir pro čtení. Lepší je přenést takové závislosti přímo do projektu.

Druhou pastí jsou session. Když se změní místo uložení, všichni návštěvníci jsou jednou odhlášeni a rozpracované nákupní košíky se ztratí. Plánujte proto přechod do klidného časového okna a interně jej oznamte.

Za třetí plánované úlohy často běží přes příkazovou řádku, a tedy pod jiným uživatelem než web. Zkontrolujte úlohy cron a fronty a nechte je běžet pod novým uživatelem webu, jinak vzniknou soubory se špatným vlastníkem, které PHP později nesmí měnit.

Konečně by každý pool měl mít vlastní hranice pro procesy a paměť. Web, který se dostane pod zátěž nebo je napaden, tak ostatní nesrazí na kolena.

Jak konkrétně pomáhá PHP SOS?

• Zjistíme, které weby dnes sdílejí uživatele, procesy a databáze.
• Pro každý web zřídíme samostatné uživatele, pooly, složky tmp a přístupy k databázi, aniž bychom aplikace měnili.
• Po přechodu každý web otestujeme a chybějící cesty cíleně opravíme.
• Oddělení zdokumentujeme jako šablonu pro budoucí projekty.

Jak to zapadá do celkové koncepce, popisuje služba Zabezpečení serveru pro webové servery PHP.

Časté dotazy

Zdroje

• php.net: bezpečnostní oznámení
• OWASP Cheat Sheet Series
• BSI IT-Grundschutz