How to Edit disable_functions on DirectAdmin and CloudLinux

[Aior]

PHP'nin disable_functions direktifi, sunucu güvenliğinin en yaygın katmanlarından biridir. Exec, shell_exec, system, passthru, proc_open gibi tehlikeli fonksiyonların kapatılması, kötü amaçlı kodun sunucuyu doğrudan komuta etmesini engeller. Ancak meşru bazı uygulamalar (örneğin yedek alma araçları, görüntü dönüşüm betikleri) bu fonksiyonlara ihtiyaç duyar. DirectAdmin + CloudLinux ortamında bu listeyi doğru biçimde düzenlemek hem güvenliği korur hem de uygulama uyumluluğunu sağlar.

1) Mevcut durumu okuma
SSH üzerinde aktif PHP sürümünün disable_functions değerini görmek için:

php82 -i | grep disable_functions

veya bir phpinfo() sayfasından arayın. AIOR'da varsayılan liste:
exec, passthru, shell_exec, system, proc_open, popen, curl_multi_exec, parse_ini_file, show_source, pcntl_exec.

2) Sunucu genelinde düzenleme
DirectAdmin CustomBuild'in PHP.ini dosyası: /usr/local/php82/lib/php.ini
Bu dosyada disable_functions = satırını bulun ve istediğiniz fonksiyonu listeden çıkarın veya ekleyin. Sonrasında PHP-FPM yeniden başlatın:

systemctl restart php-fpm82

3) Hesap bazlı override (CloudLinux PHP Selector)
CloudLinux ortamında daha güzel yöntem, kullanıcının PHP Selector ayarına özel override eklemektir. Selector v2'de "Options" sekmesinde belirli direktifler kapatılabilir/açılabilir, ancak disable_functions normalde yönetici ayarıdır. Tek kullanıcıya özel düzenleme için:

/var/cagefs/lib/etc/php82.d/user.ini

veya hesabın evinde .user.ini dosyası oluşturun (DirectAdmin'in hesap PHP Settings menüsü bunu UI'dan yapar).

4) Hangi fonksiyonu açmalı?
Çoğu CMS için disable_functions varsayılan listesi yeterlidir. Ek açma ihtiyacı genellikle:

• WHMCS otomatik yedekleme: system gerekebilir.
• ImageMagick wrapper'ları: exec gerekebilir.
• WordPress backup eklentileri: shell_exec ister.
• XenForo ElasticSearch yapılandırması: özel bir fonksiyon istemez.

İhtiyaç gerçekten varsa açın; gerekmiyorsa zorlamayın.

5) Doğrulama
Bir test betiği yazın:

<?php var_dump(function_exists('shell_exec')); ?>

Hesabın altında çalıştırın. Sonuç bool(true) ise fonksiyon kullanılabilir; bool(false) hâlâ kapalı demektir.

6) Imunify360 ile etkileşim
Imunify360 PHP Proactive Defense modülü, tehlikeli fonksiyon çağrılarını davranışsal olarak yakalar; disable_functions listesinden çıkarsanız bile Imunify exec çağrısını analiz edip blok edebilir. Bu, savunma katmanı olarak değerlidir. Çağrı yapan dosyayı false-positive olarak işaretlerseniz Imunify panel altında "Ignore Lists" ile beyaz listeye alabilirsiniz.

7) Güvenlik dengesi
disable_functions tek başına yeterli değildir; CloudLinux CageFS, dosya izinleri, ModSecurity ve PHP open_basedir bütüncül koruma sağlar. AIOR olarak yeni bir hesap açtığımızda CageFS + standart disable_functions + open_basedir kombinasyonunu varsayılan tutuyoruz.

8) Geri alma
Hatalı bir değişiklikten dönmek için php.ini dosyasının yedek kopyasını geri yükleyin ve PHP-FPM'i yeniden başlatın. Bir hesabın gereksiniminden ötürü açtığınız fonksiyon başka hesaplara sızmasın — sistem genelinde açmak yerine hesap bazlı override yapın.

PHP's disable_functions directive is one of the most common server-hardening layers. Disabling exec, shell_exec, system, passthru and proc_open prevents malicious code from running OS commands directly. But legitimate applications such as backup utilities and image converters sometimes need them. On DirectAdmin with CloudLinux, editing the list correctly preserves security while keeping legitimate apps working.

1) Read the current state
From SSH, look at the active PHP version's directive:

php82 -i | grep disable_functions

or grep it from a phpinfo() page. Our default list at AIOR:
exec, passthru, shell_exec, system, proc_open, popen, curl_multi_exec, parse_ini_file, show_source, pcntl_exec.

2) System-wide edit
DirectAdmin CustomBuild's PHP.ini lives at /usr/local/php82/lib/php.ini. Find the disable_functions = line and add or remove items. Then restart PHP-FPM:

systemctl restart php-fpm82

3) Per-account override on CloudLinux
A better practice on CloudLinux is per-account override. Selector v2 exposes an "Options" tab for some directives, but disable_functions is normally admin-only. For a single user, either:

/var/cagefs/lib/etc/php82.d/user.ini

or a .user.ini in the account's home (the DirectAdmin per-account PHP Settings UI manages this for you).

4) Which functions to allow?
For most CMSes the default list is fine. Common reasons to relax it:

• WHMCS automated backups — sometimes needs system.
• ImageMagick wrappers — exec may be required.
• WordPress backup plugins — most need shell_exec.
• XenForo ElasticSearch config — no special functions required.

Open them only when there's a real need; don't pre-emptively widen the surface.

5) Verification
Write a test script:

<?php var_dump(function_exists('shell_exec')); ?>

Run it under the user account. bool(true) confirms availability; bool(false) means it is still disabled.

6) Interaction with Imunify360
Imunify360's PHP Proactive Defense detects dangerous calls behaviourally; even when you remove a function from disable_functions, Imunify can analyse and block the call at runtime. This double-layer model is valuable. Whitelist the calling file in the Imunify panel's "Ignore Lists" if a false positive blocks a legitimate app.

7) Security balance
disable_functions alone is not enough. CloudLinux CageFS, file permissions, ModSecurity and PHP open_basedir together provide layered protection. When provisioning a new account at AIOR, we keep CageFS + the standard disable_functions list + open_basedir as the baseline.

8) Rollback
Revert a bad change by restoring the php.ini backup and restarting PHP-FPM. Avoid system-wide opens when a single account needs a function — prefer per-account override so the change doesn't leak to neighbours.