PHP Kullanan Linux Sunucular İçin Güvenlik Kuralları

yazar

PHP, web uygulamalarının büyük kısmında kullanılan sunucu tarafı bir betik dilidir. Yaşanan güvenlik ihlallerinin çoğu PHP kodundan değil, yanlış yapılandırılmış sunucu ayarlarından kaynaklanır. Özellikle varsayılan ayarlarla çalışan PHP kurulumları, paylaşımlı ortamlarda tüm sistemi riske sokabilir. Aşağıdaki önlemler, PHP’nin çalışma sınırlarını işletim sistemi seviyesinde belirlemeye odaklanır.

PHP Tarafında Sık Görülen Saldırı Türleri

PHP sistemlerinde saldırganlar genellikle hızlı sonuç veren açıkları hedefler. Aşağıdaki saldırılar, pratikte en sık karşılaşılan ve en yıkıcı etkiye sahip olanlardır.

Remote Code Execution (RCE)

PHP aracılığıyla sunucuda komut çalıştırılmasını sağlar. Tehlikeli PHP fonksiyonlarının açık bırakılması bu saldırının temel nedenidir. Etkisi kritik seviyededir.

disable_functions = exec,system,shell_exec,passthru,proc_open,popen

Dosya Yükleme Üzerinden Web Shell

Upload alanları yeterince sınırlandırılmadığında PHP dosyaları yüklenebilir. Dosya web dizini altındaysa doğrudan çalıştırılabilir.

location /uploads {
    php_admin_flag engine off;
}

Local File Inclusion (LFI)

Dinamik include işlemleri yanlış kullanıldığında ortaya çıkar. Saldırgan sistem içeriğine erişebilir ve zincirleme saldırılar başlatabilir.

open_basedir = "/var/www/site:/tmp"

SQL Injection

Kullanıcı verisi doğrudan sorguya girerse veritabanı güvenliği tehlikeye girer. Bu durum veri sızıntısına ve yetki kaybına yol açar.

SELECT * FROM users WHERE id = ?

Bu saldırılar, PHP’nin kontrolsüz çalıştığı ortamlarda kaçınılmaz hale gelir.

PHP’yi Her Zaman Güncel Tutalım

PHP güvenliğinin temel adımlarından biri, kullanılan sürümün destek altında olmasıdır. Destek süresi sona ermiş PHP 7.x sürümleri üretim ortamları için ciddi risk oluşturur.

Güncellemeler paket yöneticisi üzerinden geciktirilmeden uygulanmalı ve yükseltme süreci kontrollü ilerlemelidir.
PHP 7.4.3’ten PHP 8.x’e geçişin komut satırından nasıl yapılacağını anlatan rehber bu noktada yol göstericidir.

🟠 PHP 7.4’ü Terminal Üzerinden PHP 8.x’e Yükseltme

Dosya Sistemi Erişimini Sınırlama

PHP’nin dosya sistemiyle doğrudan çalışması, yanlış yapılandırıldığında ciddi bir saldırı yüzeyi oluşturur. Bu yüzden ilk adım, PHP’nin erişebileceği dizinlerin net biçimde sınırlandırılmasıdır.

open_basedir = "/var/www/site:/tmp"

PHP İşlemlerinin Yetkisi

PHP sürecinin root yetkisiyle çalışması, küçük bir açığın bile tüm sunucuya yayılmasına neden olabilir. Bu nedenle PHP-FPM veya CGI süreçleri düşük yetkili kullanıcılarla çalışacak şekilde yapılandırılmalıdır.

ps aux | grep php

Her uygulama için ayrı bir PHP-FPM havuzu ve kullanıcı tanımlanması gerekir. Plesk ortamlarında domain bazlı PHP-FPM havuzu ve kaynak limitleri bu ayrımı uygulamak için etkili bir yöntemdir.

Plesk’te Domainlerde PHP-FPM Yönetimi Nasıl Yapılır?

PHP Fonksiyonlarını Devre Dışı Bırak

PHP varsayılan olarak sistem komutu çalıştırabilen fonksiyonlarla gelir. Uygulama kullanmıyorsa açık kalmamalıdır.

disable_functions = exec,system,shell_exec,passthru,popen,proc_open

PHP’nin İletişimini Sınırla

Uzak dosya erişimi çoğu zaman zincirleme açıkların başlangıcıdır. Varsayılan olarak kapalı olmalıdır.

allow_url_fopen = Off
allow_url_include = Off

PHP Loglarını Ayır ve İzle

PHP error log’ları sadece debug değil, saldırı tespiti içindir. Her PHP-FPM havuzu için ayrı log dosyaları tanımlanmalıdır. Loglar merkezi sistemlere aktarılmalı ve izlenmelidir.

PHP Modüllerini Ters Mantıkla Yönet

Önce neye ihtiyaç olduğunu belirle, sonra modülleri aç. Kullanılmayan her modül ek saldırı yüzeyidir.

php -m
mv /etc/php.d/xmlrpc.ini /etc/php.d/xmlrpc.off
systemctl restart php-fpm

Dosya Yükleme Mekanizmalarını Daralt

Dosya yükleme mümkünse kapatılmalıdır. Zorunluysa sınırlandırılmalıdır.

file_uploads = On
upload_max_filesize = 2M
upload_tmp_dir = /var/lib/php/tmp

PHP Hata Mesajlarını Kullanıcıdan Gizle

Hata mesajları saldırgan için ipucu olabilir. Ekran kapalı, log açık olmalıdır.

display_errors = Off
log_errors = On
error_log = /var/log/php/runtime-error.log

Script Süresi ve Bellek Sınırları Koy

Sonsuz veya ağır script’ler saldırı olmasa bile sorundur. Temel sınırlar mutlaka tanımlanmalıdır.

max_execution_time = 30
max_input_time = 30
memory_limit = 256M

Dosya ve Dizin İzinlerini En Sona Al

En doğru zaman en sondur. Artık uygulamanın nereye yazdığını biliyorsundur.

find /var/www/site -type f -exec chmod 0444 {} \;
find /var/www/site -type d -exec chmod 0555 {} \;

SELinux ve WAF ile İkinci Savunma Katmanı

PHP ayarları ilk savunma hattıdır. SELinux ve WAF ikinci katmandır.

getsebool -a | grep httpd

Sık Sorulan Sorular

PHP-FPM kullanmak PHP güvenliğini otomatik olarak sağlar mı?

Hayır. PHP-FPM yalnızca çalışma izolasyonu sunar. Güvenlik ayarları eksikse uygulama açığı sistem seviyesine taşınabilir.

PHP uygulamasının hangi kaynaklara eriştiğini nasıl netleştiririm?

PHP-FPM sürecini sistem çağrılarıyla izlemek en net yöntemdir. Dosya ve ağ erişimleri bu şekilde görünür hale gelir.

strace -f -p $(pgrep -n php-fpm)

PHP tabanlı bir veri sızıntısını hızlıca nasıl fark ederim?

Koddan önce ağ trafiğine bakılmalıdır. PHP proseslerinin açtığı dış bağlantılar kontrol edilmelidir.

ss -tpn | grep php

Staging’de sorunsuz çalışan PHP kodu prod’da neden bozulur?

Prod ortamındaki PHP güvenlik kısıtları daha sıkıdır. disable_functions, open_basedir ve benzeri ayarlar fark yaratır. Ayarlar karşılaştırılıp kod buna göre uyarlanmalıdır.

Yorum yapın