Bölüm 26

php.ini Hardening & PHP-FPM

14 dk okuma2.821 kelimePHP 8.1+

Ön koşul

Bölüm 8 (RCE, disablefunctions), Bölüm 16 (session ayarları), Bölüm 19 (dosya yükleme), Bölüm 20 (allowurlinclude, openbasedir). İleri referanslar: Bölüm 27 (web sunucusu), Bölüm 28 (izinler), Bölüm 29 (container).

Bu bölümün kazanımı

PHP'nin çalıştırma modellerini (modphp, PHP-CGI, PHP-FPM) ve neden PHP-FPM'in tercih edildiğini; güvenlik açısından kritik php.ini direktiflerini; ve disablefunctions/openbasedir'in birer derinlemesine savunma katmanı (mutlak sınır değil) olduğunu göreceksiniz. Bu, Kısım VI'yı (Altyapı ve Dağıtım Güvenliği) açan bölümdür.

1. Giriş

Şimdiye kadar uygulama kodundaki açıklara odaklandık. Ama en kusursuz kod bile, altında çalıştığı PHP çalışma ortamı yanlış yapılandırılmışsa savunmasız kalır. php.ini ve PHP-FPM yapılandırması, uygulamanızın "işletim koşullarını" belirler: hangi tehlikeli fonksiyonlar açık, dosya erişimi ne kadar geniş, hatalar nasıl gösteriliyor, PHP hangi süreç modeliyle çalışıyor. Bu ayarlar, bir açığın "küçük bir sorun" mu yoksa "tam sistem devri" mi olacağını doğrudan etkiler.

PHP'nin çalıştırma modeli özellikle kritiktir. 2024'te DEVCORE'un açıkladığı CVE-2024-4577 (Bölüm 11), on iki yıl önce (CVE-2012-1823) kapatılmış bir açığın PHP-CGI modelinde yeniden ortaya çıkışıydı — Windows'un "Best Fit" kodlama dönüşümü, saldırganların php.exe'ye komut satırı argümanı enjekte etmesine (ve -d allow_url_include=1 -d auto_prepend_file=php://input ile RCE'ye) izin verdi. Kitlesel olarak sömürüldü. Ders açıktı: PHP-CGI kullanma; PHP-FPM kullan.

Bu bölüm, PHP çalışma ortamını sertleştirmeyi ele alır ve Kısım VI'yı (php.ini, web sunucusu, Linux izinleri, container, tedarik zinciri) açar. Buradaki tema, önceki bölümlerin savunma derinliğini altyapı katmanına taşımaktır: uygulama savunması aşılsa bile, sıkı bir ortam hasarı sınırlar (Bölüm 1).

2. Temel Teori

PHP çalıştırma modelleri:

Model	Nasıl çalışır	Güvenlik
mod_php (Apache modülü)	PHP, Apache sürecine gömülü	Web sunucusuyla aynı kullanıcı/süreç; izolasyon zayıf
PHP-CGI	Her istek için CGI süreci	Tehlikeli — argüman enjeksiyonu (CVE-2024-4577/2012-1823)
PHP-FPM (FastCGI Process Manager)	Kalıcı FPM işçi havuzu	Önerilen — süreç izolasyonu, havuz-başına kullanıcı
CLI	Komut satırı	Web dışı; cron/işçi

Neden PHP-FPM? PHP-FPM, web sunucusundan ayrı bir süreç havuzu (pool) olarak çalışır. Bu şunları sağlar: (1) her uygulama/site için ayrı havuz ve ayrı düşük yetkili kullanıcı (izolasyon, Bölüm 28); (2) argüman enjeksiyonu yüzeyinin (CGI'nin belası) olmaması; (3) çalıştırılacak uzantıların kısıtlanması (security.limit_extensions); (4) kaynak sınırları ve süreç yönetimi. PHP-CGI ise her isteği URL'den argüman çıkararak php.exe'ye geçirir — bu, CVE-2024-4577'nin kök nedenidir.

Güvenlik açısından kritik php.ini direktifleri:

Direktif	Güvenli değer	Neden
`expose_php`	`Off`	PHP sürümünü sızdırma (bilgi ifşası)
`display_errors`	`Off` (üretim)	Hata detayları saldırgana yol/kaynak sızdırır
`log_errors`	`On`	Hataları göstermek yerine logla
`allow_url_include`	`Off`	RFI (Bölüm 20)
`allow_url_fopen`	`Off` (gerekmiyorsa)	SSRF/uzak getirmeyi sınırla (Bölüm 21)
`cgi.fix_pathinfo`	`0`	nginx+FPM RCE (Bölüm 27)
`open_basedir`	Uygulama dizini	Dosya erişimini hapset (Bölüm 20)
`disable_functions`	Tehlikeli fonksiyonlar	RCE yüzeyini daralt (Bölüm 8)
`session.cookie_secure/httponly/samesite`	`On`/`On`/`Lax`	Oturum güvenliği (Bölüm 16)
`session.use_strict_mode`	`1`	Session fixation (Bölüm 16)
`enable_dl`	`Off`	Dinamik uzantı yükleme kapalı
`upload_max_filesize`/`post_max_size`	Makul sınır	DoS (Bölüm 19)
`max_input_vars`/`memory_limit`/`max_execution_time`	Makul sınır	Kaynak tüketimi DoS

Kritik nüans — disable_functions bir sınır değildir. exec, system, shell_exec, passthru, proc_open, popen gibi fonksiyonları devre dışı bırakmak, RCE yüzeyini daraltır ama mutlak bir güvenlik sınırı değildir: saldırganlar bilinen atlatmalarla (alternatif fonksiyonlar, LD_PRELOAD, FFI, PHP açıkları) bunları aşabilir. disable_functions ve open_basedir birer derinlemesine savunma katmanıdır (Bölüm 1) — tek başlarına güvenmeyin, ama ekleyin.

Güncel tut. CVE-2024-4577, ömrü dolmuş (EOL) PHP 5/7'yi de etkiledi ve yamasız kalanlar hızla ele geçirildi. Desteklenen bir PHP sürümü ve güncel yamalar, temel bir gerekliliktir.

3. Mimarisel Bakış

 GÜVENSİZ (PHP-CGI):
   İstek → web sunucusu → URL'den argüman çıkar → php-cgi.exe -d ...
        ↑ CVE-2024-4577: soft-hyphen (0xAD)→hyphen best-fit → argüman enjeksiyonu
   → -d allow_url_include=1 -d auto_prepend_file=php://input → RCE

 GÜVENLİ (PHP-FPM):
   İstek → web sunucusu → FastCGI → PHP-FPM havuzu (düşük yetkili kullanıcı)
        ↑ argüman enjeksiyonu yüzeyi YOK
        ↑ security.limit_extensions = .php (yalnızca .php çalışır)
        ↑ ayrı havuz/kullanıcı → izolasyon (Bölüm 28)
   → sıkı php.ini + open_basedir + disable_functions (derinlemesine savunma)

 php.ini SERTLEŞTİRME KATMANLARI:
   expose_php=Off (bilgi) · display_errors=Off (ifşa) · allow_url_include=Off (RFI)
   open_basedir (dosya hapsi) · disable_functions (RCE yüzeyi) · session.* (oturum)

Kritik gözlem: PHP-FPM + sıkı php.ini, uygulama katmanı aşılsa bile hasarı sınırlayan bir "işletim kabuğu" oluşturur.

4. Güvensiz Kod

Gerçekçi (güvensiz) bir php.ini / dağıtım yapılandırması:

; ⚠️ GÜVENSİZ php.ini
expose_php = On                  ; PHP sürümü başlıkta sızıyor
display_errors = On              ; üretimde hata/yol ifşası
log_errors = Off
allow_url_include = On           ; RFI (Bölüm 20)
allow_url_fopen = On
cgi.fix_pathinfo = 1             ; nginx+FPM RCE (Bölüm 27)
; open_basedir yok               ; dosya erişimi tüm sisteme açık
; disable_functions yok          ; exec/system/... hepsi açık (Bölüm 8)
session.cookie_httponly = Off    ; XSS ile çerez çalma (Bölüm 16)
session.cookie_secure = Off
session.use_strict_mode = 0      ; session fixation (Bölüm 16)

# ⚠️ GÜVENSİZ — PHP-CGI (CVE-2024-4577 yüzeyi)
AddHandler cgi-script .php
Action cgi-script "/cgi-bin/php-cgi.exe"

5. Açığın Analizi

PHP-CGI yapılandırması — CVE-2024-4577'nin doğrudan yüzeyi. Action cgi-script php-cgi.exe ile web sunucusu, isteği argümanlara çevirip php-cgi'ye geçirir. Windows "Best Fit" kodlamasıyla soft-hyphen enjeksiyonu, -d argümanlarıyla RCE'ye açar. PHP-FPM'e geçmek bu yüzeyi tümden kaldırır.

expose_php = On — X-Powered-By: PHP/8.x.x başlığı, sürüm bilgisi sızdırır; saldırgana sürüme özel açıkları hedeflemekte yardımcı olur. Off yapılmalı.

display_errors = On (üretim) — Hata mesajları dosya yolları, kaynak parçaları, SQL, yığın izleri sızdırır. Üretimde Off + log_errors = On.

allow_url_include = On — RFI (Bölüm 20); include uzak URL çalıştırır. Kesin Off.

cgi.fix_pathinfo = 1 — nginx+PHP-FPM'de, PATH_INFO manipülasyonuyla PHP-olmayan dosyaların (yüklenen görüntülerin) PHP olarak çalıştırılmasına yol açabilir (Bölüm 27, 19). 0 önerilir.

open_basedir/disable_functions yok — Dosya erişimi ve tehlikeli fonksiyonlar sınırsız; bir LFI (Bölüm 20) veya RCE (Bölüm 8) açığının etkisi maksimuma çıkar. Sınırlanmalı (derinlemesine savunma).

session.* gevşek — Oturum çerez bayrakları ve strict mode kapalı (Bölüm 16); XSS-çalma, sidejacking, fixation'a açık.

Kök sorun: çalıştırma modeli tehlikeli (CGI), bilgi sızıyor, tehlikeli özellikler açık ve hiçbir hapsetme yok. Çözüm: FPM + sıkı php.ini + hapsetme katmanları.

6. Hacker Bakış Açısı

Saldırgan PHP ortamını nasıl yoklar?

Sürüm ve modeli belirler. X-Powered-By başlığı (expose_php), hata mesajları ve davranışlardan PHP sürümünü ve çalıştırma modelini (CGI/FPM/mod_php) çıkarır. CGI tespit ederse CVE-2024-4577/2012-1823 sınıfını dener.

Hata ifşasını toplar. display_errors açıksa, tetiklediği hatalardan dosya yolları, kaynak, SQL ve yapı bilgisi toplar — sonraki saldırılar için harita.

RCE yüzeyini ölçer. Bir kod-çalıştırma açığı bulduğunda, disable_functions'ın hangi fonksiyonları kapattığını test eder ve atlatmayı dener (alternatif fonksiyonlar, FFI, LD_PRELOAD, bilinen PHP açıkları). open_basedir varsa onu da atlatmayı dener.

Ortam direktifleri enjekte etmeyi dener. CVE-2024-4577'de olduğu gibi, argüman/parametre enjeksiyonu ile allow_url_include, auto_prepend_file gibi direktifleri çalışma zamanında değiştirip RCE kurmaya çalışır.

Zayıf oturum ayarlarını kullanır. session.* gevşekse, XSS-çalma/fixation/sidejacking (Bölüm 16) ile oturum ele geçirir.

Savunmacı dersi: Saldırgan ortamı bir "zayıflık çarpanı" olarak görür — sıkı bir ortam, aynı uygulama açığının etkisini küçültür. FPM + sıkı php.ini bu çarpanı düşürür.

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. Ortam sertleştirmenin neden kritik olduğu kavramsaldır:

Çalıştırma modeli = saldırı yüzeyi. PHP-CGI, URL'yi argümana çeviren yapısıyla argüman enjeksiyonu yüzeyi taşır (CVE-2024-4577). PHP-FPM bu yüzeyi tümden kaldırır — mimari bir savunma.
Ortam, etkiyi çarpar veya böler. Aynı LFI/RCE açığı, open_basedir+disable_functions+ayrı FPM kullanıcısı olan bir sistemde sınırlı kalırken, hepsi açık bir sistemde tam devir olur. Ortam, açığın "çarpanıdır" (Bölüm 1).
Derinlemesine savunma, mutlak değil. disable_functions/open_basedir atlatılabilir; ama her katman saldırganın işini zorlaştırır ve bazı saldırıları durdurur. Bunlar sınır değil, katmandır.
Güncel olmayan sürüm = kaçınılmaz sömürü. CVE-2024-4577, EOL sürümleri yamasız bıraktığı için kitlesel sömürüldü; güncel sürüm temel bir gerekliliktir.

Araştırmacının çerçevesi: (a) çalıştırma modeli güvenli mi (FPM), (b) bilgi sızıyor mu, (c) tehlikeli özellikler/erişim sınırlı mı, (d) sürüm güncel mi. Savunma dördünü de sıkılaştırır.

8. Güvenli Kod

Sertleştirilmiş php.ini ve PHP-FPM havuz yapılandırması:

; ✅ GÜVENLİ php.ini (üretim)
expose_php = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
allow_url_include = Off
allow_url_fopen = Off              ; uzak getirme gerekmiyorsa
cgi.fix_pathinfo = 0               ; Bölüm 27
open_basedir = /var/www/app:/tmp   ; dosya erişimini hapset (Bölüm 20)
enable_dl = Off

; RCE yüzeyini daralt (derinlemesine savunma — mutlak sınır değil, Bölüm 8)
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,pcntl_exec

; Oturum (Bölüm 16)
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1
session.use_only_cookies = 1

; DoS sınırları (Bölüm 19)
upload_max_filesize = 8M
post_max_size = 10M
max_file_uploads = 20
memory_limit = 128M
max_execution_time = 30
max_input_vars = 1000

; ✅ GÜVENLİ PHP-FPM havuzu (/etc/php-fpm.d/app.conf)
[app]
user = app_php                     ; düşük yetkili, siteye özel kullanıcı (Bölüm 28)
group = app_php
listen = /run/php-fpm/app.sock
listen.owner = nginx               ; yalnızca web sunucusu bağlanabilir
listen.group = nginx
listen.mode = 0660

security.limit_extensions = .php   ; YALNIZCA .php çalışır (yüklenen .jpg çalışmaz!)
php_admin_value[open_basedir] = /var/www/app:/tmp
php_admin_flag[allow_url_include] = off

; Kaynak sınırları
pm = dynamic
pm.max_children = 20
request_terminate_timeout = 30s

Öne çıkan modern pratikler: - PHP-FPM kullan (CGI değil): Argüman enjeksiyonu yüzeyini (CVE-2024-4577) kaldırır; havuz izolasyonu sağlar. - Havuz-başına düşük yetkili kullanıcı (Bölüm 28): Her site ayrı kullanıcı; bir sitenin ele geçirilmesi diğerlerine yayılmaz. - security.limit_extensions = .php: Yalnızca .php çalışır; yüklenen .jpg/.phtml çalışmaz (Bölüm 19 ile güçlü sinerji). - Bilgi sızıntısını kapat: expose_php=Off, display_errors=Off+log_errors=On. - Tehlikeli özellikleri kapat: allow_url_include=Off, cgi.fix_pathinfo=0, enable_dl=Off. - Hapsetme katmanları: open_basedir + disable_functions (derinlemesine savunma — mutlak sınır değil). - Oturum sertleştirme (Bölüm 16): session.* bayrakları + strict mode. - DoS sınırları (Bölüm 19): Yükleme/bellek/süre/girdi sınırları. - Güncel PHP + yama: Desteklenen sürüm; CVE-2024-4577 dersi.

9. Patch Analizi

Neden işe yarar? PHP-FPM, CGI'nin argüman enjeksiyonu yüzeyini mimari olarak kaldırır ve havuz izolasyonu getirir. Sıkı php.ini, bilgi sızıntısını (expose_php/display_errors) ve tehlikeli özellikleri (allow_url_include/cgi.fix_pathinfo) kapatır. open_basedir+disable_functions+security.limit_extensions, bir uygulama açığı (LFI/RCE/upload) tetiklense bile etkisini daraltır. Bunlar birlikte, "uygulama açığı olacaktır" gerçeğini kabul edip hasarı sınırlayan bir derinlemesine savunma (Bölüm 1) kabuğu oluşturur.

Model karşılaştırması:

Model	İzolasyon	Argüman enjeksiyonu	Öneri
PHP-CGI	Zayıf	Açık (CVE-2024-4577)	Kullanma
mod_php	Web sunucusuyla ortak	Yok	Sınırlı; FPM tercih
PHP-FPM	Havuz/kullanıcı bazlı	Yok	Önerilen

disable_functions uyarısı: Bu bir sınır değil katmandır; atlatılabilir (FFI, alternatif fonksiyonlar, PHP açıkları). Yine de RCE yüzeyini daraltır ve otomatik/sıradan saldırıları durdurur. Tek savunma olarak değil, katman olarak kullanın.

Performans: PHP-FPM, kalıcı işçilerle mod_php'ye yakın veya daha iyi performans sağlar. Sıkı ayarların çalışma-zamanı maliyeti yok denecek kadar azdır. open_basedir küçük bir dosya-erişim kontrolü ekler.

10. Gerçek Hayat Senaryosu

Kurgu — paylaşımlı barındırmada çok sayıda site. Sağlayıcı, tüm siteleri tek bir mod_php/PHP-CGI altında, tek www-data kullanıcısıyla çalıştırıyor; open_basedir ve ayrı havuzlar yok. Bir sitedeki dosya yükleme açığı (Bölüm 19) bir web shell'e dönüşünce, saldırgan www-data yetkisiyle diğer tüm sitelerin dosyalarını okuyup değiştirebiliyor (yatay yayılım). Ayrıca CGI modeli CVE-2024-4577'ye açık. Doğru mimari: her site ayrı PHP-FPM havuzu + ayrı düşük yetkili kullanıcı + open_basedir + security.limit_extensions=.php. Dersler: (1) izolasyon (havuz/kullanıcı) yatay yayılımı durdurur; (2) FPM, CGI'nin enjeksiyon yüzeyini kaldırır; (3) open_basedir + .php kısıtı, bir sitenin açığını o siteyle sınırlar.

11. Gerçek CVE Analizi — PHP-CGI Argüman Enjeksiyonu (CVE-2024-4577)

DEVCORE danışması, Qualys/Censys/GreyNoise ve PHP resmi ChangeLog'u ile doğrulanmıştır. Silahlaştırılmış payload verilmez.

Özet. Haziran 2024'te DEVCORE, PHP-CGI'de kritik bir argüman enjeksiyonu → RCE açığı (CVE-2024-4577, CVSS 9.8) açıkladı; PHP 6 Haziran 2024'te yamaladı (8.3.8/8.2.20/8.1.29). Açık, 2012'de kapatılmış CVE-2012-1823'ün bir yama atlatmasıydı. Shadowserver 6 Haziran'da kitlesel sömürü gözlemledi; GreyNoise Ocak 2025'te tek ayda 1.000'den fazla saldıran IP ve 79 hazır exploit kiti saydı. CISA KEV'e girdi.

Teknik neden — Windows "Best Fit" + PHP-CGI argüman yüzeyi. PHP-CGI modelinde, web sunucusu HTTP isteğinden nitelikleri çıkarıp php.exe'ye komut satırı argümanı olarak geçirir. CVE-2012-1823 yaması, argüman sınırlayıcısı olan tire (-, 0x2D) karakterlerini filtreliyordu. Ancak Windows'un "Best Fit" kodlama dönüşümü, "soft hyphen" (yumuşak tire, 0xAD) karakterini standart tireye (0x2D) eşliyordu. Apache gerçek tireyi kaçırıyor (escape) ama soft-hyphen'i kaçırmıyordu; PHP ise Unicode işlemesinde best-fit eşlemesini uygulayıp soft-hyphen'i gerçek tire olarak yorumluyordu. Sonuç: saldırgan, soft-hyphen ile php.exe'ye argüman enjekte edebiliyordu. RCE'ye çevirmek için -d allow_url_include=1 -d auto_prepend_file=php://input argümanları enjekte ediliyor; böylece HTTP istek gövdesindeki PHP kodu çalıştırılıyordu.

Kritik dersler: (1) bu, PHP-CGI modelinin yapısal bir riskidir; PHP-FPM'de bu argüman yüzeyi yoktur. (2) allow_url_include gibi php.ini direktiflerinin çalışma zamanında enjekte edilebilmesi, onların neden sıkı ve değiştirilemez (php_admin_*) olması gerektiğini gösterir. (3) On yıl önce kapatılan bir açık, bir kenar-durum (Windows best-fit) yüzünden geri döndü — güvenlik "bitmiş" bir iş değildir.

Etki. Kimlik doğrulamasız RCE; XAMPP (Windows'ta öntanımlı savunmasız) yaygınlığı nedeniyle devasa taban; kripto madenciliği, ransomware ve yanal hareket için kullanıldı. EOL PHP 5/7 de etkilendi ve yamalanamadığından kalıcı risk oluşturdu.

Satıcı düzeltmesi ve önerilen mitigasyon. PHP yamaladı; ayrıca DEVCORE ve savunmacılar PHP-CGI'yi terk edip PHP-FPM'e geçmeyi birincil kalıcı çözüm olarak önerdi.

Çıkarılacak dersler: 1. PHP-CGI kullanma; PHP-FPM kullan. Argüman enjeksiyonu yüzeyini mimari olarak kaldırır. 2. php.ini direktiflerini kilitle. php_admin_value/php_admin_flag ile çalışma-zamanı değişimini engelle; allow_url_include=Off. 3. Güncel ve desteklenen sürüm kullan. EOL sürümler yamalanmaz; CVE-2024-4577 bunun bedelini gösterdi.

12. Detection

Yapılandırma incelemede:

php -i | grep -iE 'expose_php|display_errors|allow_url_include|cgi.fix_pathinfo|open_basedir|disable_functions'
grep -riE 'AddHandler cgi-script|php-cgi' /etc/apache2 /etc/httpd   # PHP-CGI kullanımı?
php -v   # sürüm güncel/destekli mi?

Kontroller: FPM mi CGI mi? expose_php/display_errors Off mu? allow_url_include Off mu? open_basedir/disable_functions var mı? Sürüm güncel mi?

SAST/yapılandırma tarama: Güvensiz php.ini direktifleri ve PHP-CGI kullanımı için kurallar (ör. CIS PHP Benchmark denetimleri).

DAST: X-Powered-By başlığı (expose_php), hata sızıntısı (display_errors), ve CVE-2024-4577 için argüman enjeksiyonu testleri.

Loglar/SIEM: PHP-CGI argüman enjeksiyonu denemeleri (URL'de %AD/soft-hyphen, allow_url_include/auto_prepend_file dizeleri); web sürecinden beklenmeyen alt süreçler (Bölüm 8); hata loglarında olağandışı yol/kaynak ifşası. CVE-2024-4577 saldırılarında php-cgi çağrılarına eklenen -d argümanları en net izdir.

13. Prevention

PHP-FPM kullan: CGI'yi terk et; havuz-başına düşük yetkili kullanıcı (Bölüm 28).
security.limit_extensions = .php: Yalnızca .php çalışsın (Bölüm 19).
Bilgi sızıntısını kapat: expose_php=Off, display_errors=Off+log_errors=On.
Tehlikeli özellikleri kapat: allow_url_include=Off, cgi.fix_pathinfo=0, enable_dl=Off.
Hapsetme katmanları: open_basedir + disable_functions (derinlemesine savunma — atlatılabilir, ama ekle).
Direktifleri kilitle: php_admin_value/php_admin_flag ile çalışma-zamanı değişimini engelle.
Oturum + DoS sınırları: session.* (Bölüm 16), yükleme/bellek/süre sınırları (Bölüm 19).
Güncel PHP + yama.

14. Mitigation

Acil: PHP-CGI'yi kapat/PHP-FPM'e geç; PHP'yi yamalı sürüme yükselt (CVE-2024-4577); allow_url_include/display_errors/expose_php gibi kritik direktifleri düzelt.
Geçici: WAF'ta argüman enjeksiyonu (soft-hyphen) kuralı; loglardan sömürü/web shell tara (Bölüm 34); sızmış sırları döndür.
Kalıcı: FPM havuz izolasyonu + security.limit_extensions + open_basedir + kilitli direktifleri standartlaştır; yapılandırma taramasını (CIS Benchmark) CI'a ekle; yama sürecini kur.

15. Checklist

[ ] PHP-FPM kullanılıyor mu (PHP-CGI değil — CVE-2024-4577)?
[ ] Her havuz ayrı, düşük yetkili kullanıcıyla mı çalışıyor (Bölüm 28)?
[ ] security.limit_extensions = .php ayarlı mı (yüklenen dosya çalışmaz — Bölüm 19)?
[ ] expose_php=Off, display_errors=Off, log_errors=On mu?
[ ] allow_url_include=Off, cgi.fix_pathinfo=0, enable_dl=Off mu?
[ ] open_basedir ve disable_functions ayarlı mı (derinlemesine savunma)?
[ ] Kritik direktifler php_admin_* ile kilitli mi?
[ ] session.* bayrakları + use_strict_mode ayarlı mı (Bölüm 16)?
[ ] Yükleme/bellek/süre/girdi sınırları var mı (Bölüm 19 DoS)?
[ ] PHP sürümü güncel ve destekli mi?

16. Laboratuvar

Lab 26.1 — expose_php/display_errors. İzole ortamda bu ikisini On/Off arasında değiştir; başlıkta sürüm sızıntısını ve bir hatada yol/kaynak ifşasını gözlemle. Üretim ayarlarına geç.

Lab 26.2 — open_basedir. Bir LFI (Bölüm 20) senaryosunda open_basedir olmadan /etc/passwd'a eriş; open_basedir ekleyip erişimin kapandığını gör.

Lab 26.3 — security.limit_extensions. Bir FPM havuzunda .php dışı bir dosyayı çalıştırmayı dene; security.limit_extensions=.php ile çalışmadığını doğrula (Bölüm 19'a bağla).

Lab 26.4 — disable_functions (ve sınırı). system gibi bir fonksiyonu devre dışı bırak; çağrının başarısız olduğunu gör. Sonra bunun neden mutlak bir sınır olmadığını (kavramsal atlatmalar) yaz.

17. Quiz

PHP'nin dört çalıştırma modeli nedir? Neden PHP-FPM önerilir?
PHP-CGI neden tehlikelidir (CVE-2024-4577/2012-1823)?
expose_php ve display_errors neden Off olmalıdır?
allow_url_include ve cgi.fix_pathinfo hangi açıklara (Bölüm 20, 27) yol açar?
open_basedir ne yapar ve hangi açığın etkisini sınırlar?
disable_functions neden bir "sınır" değil "katman"dır?
security.limit_extensions=.php neden Bölüm 19 ile güçlü sinerji yapar?
Havuz-başına ayrı kullanıcı, paylaşımlı barındırmada neyi önler?
php_admin_value/php_admin_flag neden php_value'dan daha güvenlidir?
CVE-2024-4577'de "Best Fit" kodlama nasıl bir rol oynadı?
CVE-2024-4577 neden EOL PHP sürümleri için kalıcı bir risktir?
Sıkı bir ortam, bir uygulama açığının "çarpanını" nasıl düşürür?

18. Kaynakça

PHP Manual, Runtime Configuration (php.ini directives), PHP-FPM configuration (security.limit_extensions, pool user).
OWASP, PHP Configuration Cheat Sheet; CIS PHP Benchmark.
MITRE / NVD, CVE-2024-4577 ve CVE-2012-1823; DEVCORE, Security Alert: CVE-2024-4577 danışması.
Qualys ThreatPROTECT, Censys ve GreyNoise, CVE-2024-4577 sömürü analizleri; PHP resmi ChangeLog (8.3.8).
MITRE, CWE-88 (Argument Injection), CWE-200 (Information Exposure).