open_basedir og isolation pr. website

Kort sagt: open_basedir begrænser de mapper, som PHP må tilgå. Alene er det blot en ekstra spærring. Virksom isolation pr. website opstår først i samspil: egen systembruger, egen PHP-FPM-pool, egen temp-mappe og egne databaseadgange. Så forbliver et indbrud i ét website begrænset til dette website.

Hvorfor isolation efter PHP2Shell afgør skadens omfang

På mange servere kører flere websites side om side: firmasitet, en shop, en gammel kampagneside, hos bureauer ofte dusinvis af kundeprojekter. Ofte deler de en systembruger og en PHP-proces. Bliver ét af dem kompromitteret, ligger alle de andre åbne.

PHP2Shell gør denne risiko håndgribelig. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 muliggør kørsel af skadelig kode uden login, uafhængigt af CMS'et. Ifølge medierapporter var der allerede den 17.10.2026 et første angrebsforsøg, rettelserne fulgte den 21.10. Løsningen er opdateringen. Om et angreb i tiden før rammer ét eller ti websites, afgør dog isolationen.

Netop ved den anden sårbarhed kommer en yderligere tanke til: Ifølge PHP-projektet kan en forespørgsels interne tilstand blive bestående i en worker og blive brugt af en senere forespørgsel i samme worker. Adskilte pools pr. website sørger for, at websites under alle omstændigheder ikke deler workere.

Hvad open_basedir kan

Med open_basedir fastlægger I en liste af mapper. PHP's filfunktioner som fopen, include eller file_get_contents nægter så adgang til alt uden for denne liste. Et indsmuglet script kan på den måde ikke uden videre læse nabowebsitets konfigurationsfiler.

Grænserne er vigtige: Kontrollen foregår inde i PHP. Programmer, der startes uden for PHP, er ikke underlagt den, og fejl i fortolkeren kan omgå den. Derfor hører open_basedir altid sammen med spærrede systemfunktioner, som beskrevet i vejledningen Brug disable_functions korrekt, og især med adskillelse på operativsystemniveau.

Isolation pr. website i fire lag

En pålidelig adskillelse bygger på flere lag. Hvert lag fanger det, som det foregående ikke klarer.

Ved højt beskyttelsesbehov, f.eks. ved shops med betalingsafvikling eller portaler med sundhedsdata, kommer containere eller adskilte servere til.

Konfigurér open_basedir i PHP-FPM-poolen

Det følgende eksempel viser en pool til et website med egen bruger seite1. Stier og versionsnummer tilpasser I til jeres system.

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

Den sidste linje sætter samtidig PHP2Shell-overgangsforanstaltningen fra php.net. Den virker kun fra pool, php.ini eller serverkonfiguration, ikke via ini_set() eller .user.ini. Mapperne opretter I med passende rettigheder:

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

Hvordan rettighederne i selve webmappen bør se ud, beskriver vejledningen Filrettigheder på webserveren.

Tilslut webserveren og kontrollér resultatet

I Nginx peger hvert website på sin egen socket. Så havner ingen forespørgsel i et andet websites pool.

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

Yderligere henvisninger til denne kombination finder I under Sikr Nginx med PHP-FPM. Efter genstarten kontrollerer I, om poolene faktisk kører adskilt:

sudo systemctl restart php8.3-fpm
# Hver pool bør køre under sin egen bruger
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"

Test derefter alle funktioner på websitet: uploads, billedbehandling, caches, planlagte opgaver. Fejlmeddelelser med henvisning til open_basedir restriction i fejlloggen viser, hvilken sti der stadig mangler. Tilføj kun stier, som applikationen virkelig har brug for, og aldrig hele filsystemet.

Typiske faldgruber ved omstillingen

Omstillingen til adskilte pools kan planlægges, men har nogle tilbagevendende fælder. Den hyppigste berører fælles anvendte biblioteker: Ligger f.eks. et framework eller en mappe med skrifttyper uden for websitets mappe, skal denne sti optages læsende i open_basedir. Bedre er det at hente sådanne afhængigheder ind i selve projektet.

Den anden fælde er sessioner. Skifter lagringsstedet, bliver alle besøgende logget af én gang, og igangværende indkøbskurve går tabt. Planlæg derfor omstillingen i et roligt tidsvindue, og varsl den internt.

For det tredje kører planlagte opgaver ofte via kommandolinjen og dermed under en anden bruger end websitet. Kontrollér cronjobs og køer, og lad dem køre under den nye website-bruger, ellers opstår der filer med forkert ejer, som PHP senere ikke må ændre.

Endelig bør hver pool have egne grænser for processer og hukommelse. Et website, der kommer under belastning eller angribes, kan så ikke tvinge de andre i knæ.

Hvordan hjælper PHP SOS konkret?

• Vi kortlægger, hvilke websites der i dag deler bruger, processer og databaser.
• Vi opretter egne brugere, pools, temp-mapper og databaseadgange pr. website uden at ændre applikationerne.
• Vi tester hvert website efter omstillingen og udbedrer manglende stier målrettet.
• Vi dokumenterer adskillelsen som skabelon til fremtidige projekter.

Hvordan det passer ind i et samlet koncept, beskriver ydelsen Serverhærdning til PHP-webservere.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• OWASP Cheat Sheet Series
• BSI IT-Grundschutz (det tyske forbundskontors grundbeskyttelse for IT)