Php disable_functions for cPanel Shared hosting

WillGrehem

Hello guys,

Please check my disable_functions if this correct enought and i ignored all bad things?

Thank you!

disable_functions = show_source, allow_url_fopen, parse_ini_file, open_base, symlink, phpinfo, apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode

PetaByet

Why do you disable eval, phpinfo and the ftp functions?

WillGrehem

@PetaByet said:
Why do you disable eval, phpinfo and the ftp functions?

For cPanel Security? One of the big shared hosting said me this. But i want to ask there too

khuongcomputer

WillGrehem said: For cPanel Security? One of the big shared hosting said me this. But i want to ask there too

As an experienced user, I will want to use phpinfo to know about my shared hosting's modules and which I can use (for example if php_gd installed or not).

And eval is just merely executes php code, no need to disable it if you have disabled other "system" php functions.

And what about my php backup code which uses ftp to transfer the file to a remote backup server?

WillGrehem

@khuongcomputer said:
And what about my php backup code which uses ftp to transfer the file to a remote backup server?

Then this should be enought?

disable_functions = show_source, system, shell_exec, passthru, phpinfo, popen, proc_open, allow_url_fopen, eval, exec, parse_ini_file, open_base, symlink

khuongcomputer

system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open, fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file, chdir, mkdir, rmdir, chmod, rename, filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo

These should be enough.

wych

I wouldn't use the first blocklist you posted, the 2nd looks slightly more reasonable.

PetaByet

@khuongcomputer said:

system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open, fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file, chdir, mkdir, rmdir, chmod, rename, filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo

>

These should be enough.

Are these going to be disabled or enabled? Most of them are very useful.

linuxthefish

exec,passthru,shell_exec,system,proc_open,popen,show_source should be enough, never had any issues with just these disabled.

You should be able to create custom php.ini with no disabled functions for clients that have issues with what you have disabled.

comXyz

@linuxthefish said:
exec,passthru,shell_exec,system,proc_open,popen,show_source should be enough, never had any issues with just these disabled.

I will add pcntl_exec to the list

upfreak

As per CSF, the following are recommended to be disabled in a shared hosting environment. You may modify them based on your usage and user requirements.

You should modify /usr/local/lib/php.ini and set:
enable_dl = Off
This prevents users from loading php modules that affect everyone on the server. Note that if use dynamic libraries, such as ioncube, you will have to load them directly in the PHP configuration (usually in /usr/local/lib/php.ini)

You should modify the PHP configuration and disable commonly abused php functions, e.g.:
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, allow_url_fopen
Some client web scripts may break with some of these functions disabled, so you may have to remove them from this list

You should consider adding ini_set to the disable_functions in the PHP configuration as this setting allows PHP scripts to override global security and performance settings for PHP scripts. Adding ini_set can break PHP scripts and commenting out any use of ini_set in such scripts is advised

coolice

Use cloudlinux + CageFS, Better Linux Cloack FS or Jail Apache Virtual Hosts + not allow Jailed /bin /usr/bin mounted suid (default option) and got customers properly isolated.... disabling functions give you false sense of security...

WillGrehem

Followed this tutorial:

http://www.eukhost.com/blog/webhosting/dangerous-php-functions-must-be-disabled/

coolice

how i say it gives you false sense of security...

ok you disable options so users cannot use php shell but if you, do not disable custom php.ini they can be easy enabled, if you disable custom php.ini's user need to contact you / your support to make changes for every script (same for ini_set)... then came that if you allow cgi an abuser simply can upload cgi shell script and skip your php disabled functions (or you will completely disable cgi) ... then came simlink race condition the simplest way to addres that is by allowin them only if owner mach but users which copy .htaccess form internet will have problems with that that came back to contacting support... ... ...

Then after some time you came to the solution, maybe isolating users properly in the first place is not such bad idea... if they are isolated disabling functions is irelevant thing

P.S Some of the bloggers on the internet do not have full idea what they talk about