open_basedir un izolācija katrai vietnei

Īsi: open_basedir ierobežo direktorijus, kuriem PHP drīkst piekļūt. Atsevišķi tā ir tikai papildu barjera. Efektīva izolācija katrai vietnei rodas tikai sadarbībā: savs sistēmas lietotājs, savs PHP-FPM pūls, sava pagaidu mape un savas datubāzes piekļuves. Tad ielaušanās vienā vietnē paliek ierobežota ar šo vietni.

Kāpēc izolācija pēc PHP2Shell nosaka zaudējumu apmēru

Daudzos serveros blakus darbojas vairākas vietnes: uzņēmuma vietne, veikals, sena kampaņas vietne, aģentūrām bieži desmitiem klientu projektu. Bieži tās dala vienu sistēmas lietotāju un vienu PHP procesu. Ja viena tiek kompromitēta, visas pārējās ir atklātas.

PHP2Shell šo risku padara taustāmu. Ievainojamības CVE-2026-109618 un CVE-2026-109619 ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās neatkarīgi no CMS. Saskaņā ar plašsaziņas līdzekļu ziņojumiem pirmais uzbrukuma mēģinājums bija jau 17.10.2026, ielāpi sekoja 21.10. Labojums ir atjauninājums. Taču tas, vai uzbrukums iepriekšējā laikā skar vienu vai desmit vietnes, ir izolācijas jautājums.

Īpaši otras ievainojamības gadījumā rodas vēl viena doma: saskaņā ar PHP projektu pieprasījuma iekšējais stāvoklis var saglabāties darbprocesā un to var izmantot vēlāks pieprasījums tajā pašā darbprocesā. Nodalīti pūli katrai vietnei nodrošina, ka vietnes darbprocesus tāpat nedala.

Ko open_basedir dara

Ar open_basedir nosakāt direktoriju sarakstu. PHP failu funkcijas, piemēram, fopen, include vai file_get_contents, tad atsaka piekļuvi visam ārpus šī saraksta. Ievadīts skripts tā nevar bez ierunām nolasīt kaimiņvietnes konfigurācijas failus.

Robežas ir svarīgas: pārbaude notiek PHP iekšienē. Programmām, kas tiek startētas ārpus PHP, tā nav spēkā, un kļūdas interpretatorā to var apiet. Tāpēc open_basedir vienmēr jālieto kopā ar bloķētām sistēmas funkcijām, kā aprakstīts ceļvedī PHP disable_functions pareiza lietošana, un galvenokārt kopā ar nodalīšanu operētājsistēmas līmenī.

Izolācija katrai vietnei četros slāņos

Noturīga nodalīšana balstās uz vairākiem slāņiem. Katrs noķer to, ko iepriekšējais nespēj.

Augstas aizsardzības vajadzības gadījumā, piemēram, veikaliem ar maksājumu apstrādi vai portāliem ar veselības datiem, klāt nāk konteineri vai atsevišķi serveri.

open_basedir konfigurēšana PHP-FPM pūlā

Turpmākais piemērs rāda pūlu vietnei ar savu lietotāju seite1. Ceļus un versijas numuru pielāgojiet savai sistēmai.

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

Pēdējā rinda uzreiz iestata arī php.net pagaidu pasākumu pret PHP2Shell. Tas darbojas tikai no pūla, php.ini vai servera konfigurācijas, nevis ar ini_set() vai .user.ini. Mapes izveidojiet ar piemērotām tiesībām:

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

Kādām jābūt tiesībām pašā tīmekļa direktorijā, apraksta ceļvedis Failu tiesības tīmekļa serverī.

Tīmekļa servera pieslēgšana un rezultāta pārbaude

Nginx katra vietne norāda uz savu socket. Tā neviens pieprasījums nenonāk citas vietnes pūlā.

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

Papildu norādes par šo kombināciju atradīsiet rakstā Nginx ar PHP-FPM nostiprināšana. Pēc pārstartēšanas pārbaudiet, vai pūli patiešām darbojas nodalīti:

sudo systemctl restart php8.3-fpm
# Katram pūlam jādarbojas zem sava lietotāja
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"

Pēc tam pārbaudiet visas vietnes funkcijas: augšupielādes, attēlu apstrādi, kešatmiņas, ieplānotos uzdevumus. Kļūdu paziņojumi ar norādi uz open_basedir restriction kļūdu žurnālā rāda, kāds ceļš vēl trūkst. Papildiniet tikai ceļus, kas lietojumprogrammai patiešām vajadzīgi, un nekad visu failu sistēmu.

Tipiski šķēršļi pārejas laikā

Pāreja uz nodalītiem pūliem ir plānojama, taču tai ir dažas atkārtotas lamatas. Biežākā skar kopīgi lietotas bibliotēkas: ja, piemēram, ietvars vai mape ar fontiem atrodas ārpus vietnes direktorija, šis ceļš lasīšanai jāiekļauj open_basedir. Labāk ir šādas atkarības ievilkt pašā projektā.

Otras lamatas ir sesijas. Ja mainās glabāšanas vieta, visi apmeklētāji reizi tiek atteikti, un notiekošie pirkumu groziņi pazūd. Tāpēc pāreju plānojiet mierīgā laika logā un paziņojiet par to iekšēji.

Treškārt, ieplānotie uzdevumi bieži darbojas caur komandrindu un tātad zem cita lietotāja nekā vietne. Pārbaudiet cron uzdevumus un rindas un liciet tiem darboties zem jaunā vietnes lietotāja, citādi rodas faili ar nepareizu īpašnieku, ko PHP vēlāk vairs nedrīkst mainīt.

Visbeidzot, katram pūlam jābūt savām robežām procesiem un atmiņai. Vietne, kas nonāk zem slodzes vai tiek uzbrukta, tā nevar citas ievilkt līdzi.

Kā PHP SOS palīdz konkrēti?

• Apzinām, kuras vietnes šodien dala lietotājus, procesus un datubāzes.
• Katrai vietnei ierīkojam savus lietotājus, pūlus, pagaidu mapes un datubāzu piekļuves, nemainot lietojumprogrammas.
• Pēc pārejas pārbaudām katru vietni un mērķtiecīgi novēršam trūkstošos ceļus.
• Nodalīšanu dokumentējam kā veidni nākamajiem projektiem.

Kā tas iekļaujas kopējā koncepcijā, apraksta pakalpojums Servera nostiprināšana PHP tīmekļa serveriem.

Biežāk uzdotie jautājumi

Avoti

• php.net: drošības ziņojumi
• OWASP Cheat Sheet Series
• BSI IT-Grundschutz