mod_php izskaidrots: PHP Apache procesā

Īsi: mod_php ir PHP kā modulis Apache tīmekļa serverī. Katrs Apache process tad satur pilnu PHP interpretatoru un pats izpilda PHP kodu; SAPI saucas apache2handler. Tas ir viegli iestatāms, taču sasaista PHP ar Apache, parasti prasa prefork MPM un gandrīz neļauj nošķirt vietnes. PHP rokasgrāmata jaunām instalācijām no tā atrunā, un PHP2Shell gadījumā PHP komanda risku mod_php gadījumā vērtē visaugstāk.

Kas ir mod_php?

mod_php gadījumā Apache ielādē PHP kā atsevišķu moduli savos procesos. Atsevišķa PHP pakalpojuma nav: kad Apache jāpiegādā .php fails, to pašu PHP kodu izpilda tas pats process, kas pieņēma pieprasījumu. Daudzus gadus tas bija standarta veids, kā darbināt PHP, un vecākos serveros un dažos Docker attēlos tas ir izplatīts vēl šodien.

Saskaņā ar PHP rokasgrāmatu PHP kā servera modulis konfigurāciju nolasa tikai vienreiz, startējot tīmekļa serveri. php.ini izmaiņas un moduļa atjauninājumi tāpēc stājas spēkā tikai pēc Apache pārstartēšanas.

Svarīgi saprast: Apache procesi dzīvo ilgi. Process pēc kārtas pieņem daudzus savienojumus, pirms tiek nomainīts; cik daudzus, regulē Apache direktīva MaxConnectionsPerChild. Iegultais PHP interpretators šajā laikā paliek tas pats. Kas diskā nomaina bibliotēku libphp, darbojošos procesu neietekmē.

Vadībai un projektu vadītājiem to var apkopot šādi: mod_php gadījumā tīmekļa serveris un PHP ir viena vienība. Kas pieskaras vienam, ietekmē otru. PHP atjauninājums nozīmē tīmekļa servera pārstartēšanu, kļūda PHP darbojas ar tīmekļa servera tiesībām, un vairāku vietņu nošķiršana vienā serverī ir gandrīz neiespējama.

Kā mod_php tiek pieslēgts?

PHP rokasgrāmata parāda pieslēgšanu divos soļos: ielādēt moduli un noteikt, kurus failus PHP jāapstrādā.

LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Rokasgrāmata iesaka FilesMatch ar SetHandler, nevis tikai AddType, lai augšupielādēti faili, piemēram, bild.php.jpg, netiktu izpildīti kā PHP. Debian un Ubuntu šo darbu veic pakotnes, piemēram, libapache2-mod-php8.3, un komandas a2enmod un a2dismod.

Vai mod_php ir aktīvs, var pārbaudīt tikai lasot:

apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # RHEL saime
apachectl -V | grep -i mpm               # aktīvais MPM (prefork, worker, event)

Prefork, Thread Safety un resursi

Apache sadala pieprasījumus ar Multi-Processing moduli (MPM). Saskaņā ar PHP rokasgrāmatu mod_php nepieciešams prefork MPM, ja PHP nav būvēts ar Zend Thread Safety (--enable-zts). Lielākā daļa distributīvu pakotņu ir būvētas bez Thread Safety.

Prefork nozīmē: viens process uz vienu vienlaicīgu savienojumu, un katrs process nes pilnu PHP interpretatoru. Arī pieprasījumi pēc attēliem vai CSS failiem tādējādi aizņem procesu ar PHP bagāžā. Tas maksā atmiņu un ierobežo slodzi, ko serveris var izturēt.

Rokasgrāmata tāpēc visām modernajām instalācijām iesaka PHP-FPM ar mod_proxy_fcgi: labāku resursu pārvaldību, procesu nošķiršanu, PHP pārstartēšanu bez Apache pārstartēšanas un saderību ar event MPM, kas kopš Apache 2.4 ir standarts. Pamatus skatiet sadaļā PHP-FPM izskaidrots.

Iestatījumi ar .htaccess, php_value un php_admin_value

Ar mod_php PHP iestatījumus var iestatīt tieši Apache konfigurācijā. Rokasgrāmata atšķir izmaiņu režīmus: ieraksti ar INI_PERDIR drīkst atrasties php.ini, .htaccess vai httpd.conf, ieraksti ar INI_SYSTEM tikai php.ini vai httpd.conf.

# VirtualHost konfigurācijā: lietojumprogrammai bloķēts
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Iespējams failā .htaccess, bet lietojumprogramma var pārrakstīt
php_value max_execution_time 60

php_admin_value un php_admin_flag ir atļauti tikai servera konfigurācijā, nevis .htaccess. Tieši šī atšķirība ir svarīga PHP2Shell pagaidu pasākumos, jo tādas vērtības kā session.upload_progress.enabled lietojumprogramma nedrīkst atiestatīt.

mod_php un PHP2Shell: kāpēc risks ir visaugstākais

PHP komanda PHP2Shell radīto risku mod_php gadījumā vērtē visaugstāk: tur exploit tika demonstrēts, vēl pirms tiek izpildīts lietojumprogrammas kods. Drošības spraudņi vai pārbaudes CMS tādējādi pienāk par vēlu. Turklāt mod_php gadījumā PHP darbojas ar tīmekļa servera tiesībām un tā atmiņā. Detalizētu klasifikāciju skatiet sadaļā Kāpēc mod_php rada augstāko risku.

Operatoriem tāpēc ir spēkā:

1. PHP moduli atjaunināt uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 vai apstiprinātu backport.
2. Apache pārstartēt pilnībā, ne tikai pārlādēt, un pārbaudīt procesu startēšanas laiku.
3. Pagaidu vērtības iestatīt ar php_admin_value servera konfigurācijā, ja atjauninājums vēl nav iespējams.
4. Pēc tam plānot pāreju uz PHP-FPM, kā aprakstīts sadaļā Apache ar mod_php aizsardzība.

Kā PHP SOS palīdz konkrēti?

• Atpazīt: Mēs pārbaudām, kuros serveros darbojas mod_php, ar kuru MPM un no kura pakotņu avota.
• Ielāpot: Mēs atjauninām PHP moduli, pilnībā pārstartējam Apache un pierādām stāvokli.
• Nodrošināt pāreju: Kur atjauninājumu kaut kas bloķē, php.net pasākumus mēs iestatām bloķētus servera konfigurācijā.
• Pārslēgt: Servera nostiprināšanas ietvaros mēs testētu migrējam uz PHP-FPM ar atsevišķiem pūliem.

Biežāk uzdotie jautājumi

Avoti

• PHP rokasgrāmata: Apache 2 sistēmā Unix
• PHP rokasgrāmata: INI izmaiņu režīmi
• Apache dokumentācija
• php.net: drošības paziņojumi