Most secure PHP configuration

[mrdinkle]

Hi There,

I am testing out a VPS at the moment and want to ensure that my server is exposed as little as possible to php exploits. What is the most secure configuration?

I appreciate that this in itself is only a slice of the php security pie and that poorly coded scripts are the main problem.

Out of the box it is set thusly:

Default PHP Version (.php files) 5
PHP 5 Handler dso
PHP 4 Handler none

Apache suEXEC on

Does this mean it is suPHP?

Thanks

[chinmay]

Hi there.

As per the output it seems that the Suexec is enabled. For more detailed info follow the steps as mentioned below.
Try executing the command as below to check if the server is suexec and suphp enabled.

root@server [~]# /usr/local/cpanel/bin/rebuild_phpconf --current

For suphp ans suexec you should get the output as below.

Available handlers: suphp dso cgi none
DEFAULT PHP: 5
PHP4 SAPI: none
PHP5 SAPI: dso
SUEXEC: enabled

[chinmay]

Enabling PHP suEXEC
When PHP runs as an Apache Module it executes as the "user/group" of the webserver which is usually "nobody" or "apache". Suexec is a mechanism supplied with Apache that allows to execute CGI scripts as the user they belong to, rather than Apache’s user. This improves security in situations where multiple mutually distrusting users have the possibility to put CGI content on the server.
This means the scripts are executed as the user that created them. If user "supp0rt" uploaded a PHP script, you would see it was "supp0rt" running the script when looking at the running processes on your server. It also provides an additional layer of security where script permissions can’t be set to 777 (read/write/execute at user/group/world level).
Note :-
Switching to the PHP Suexec module on the servers affects the users that depended on the configuration in the .htaccess file are panicking because their site not works anymore. This is not really a reason to be panic, what can you do in this situation is simple. Try to move as much configurations from your .htaccess file to the php.ini file. The php.ini is a simple text file that can be places in every directory from your server. It will affect only that directory and not the entire site. In addition, there could be some performance loss (also known as seeing a higher server load) as a result of all php scripts being ran as a separate CGI instead of as part of the Apache module.

Disable dangerous PHP functions
Some PHP functions are termed to be highly dangerous and these PHP functions should be left disabled in the configuration. Using an insecure PHP script as an entry point to a web hosting server can start unleashing dangerous commands and take control over the complete server.
Following is the complete list of such PHP functions which are needed to be disabled, so that it can't be executed from the server.
Locate the php.ini file of your server

[root@server ~]# php -i | grep php.ini

Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => /usr/local/lib/php.ini
[root@server ~]#
Now edit this file,

[root@server ~]# pico /usr/local/lib/php.ini

Search for "disable_functions" [without quote] within that configuration file & modify it from disable_functions = to

disable_functions = "system,passthru,exec,popen,proc_close,proc_get_st atus,proc_nice,proc_open,proc_terminate,shell_exec ,highlight_file,escapeshellcmd,define_syslog_varia bles,posix_uname,posix_getpwuid,apache_child_termi nate,posix_kill,posix_mkfifo,posix_setpgid,posix_s etsid,posix_setuid,escapeshellarg,posix_uname,ftp_ exec,ftp_connect,ftp_login,ftp_get,ftp_put,ftp_nb_ fput,ftp_raw,ftp_rawlist,ini_alter,ini_restore,inj ect_code,syslog,openlog,define_syslog_variables,ap ache_setenv,mysql_pconnect,eval,phpAds_XmlRpc,phpA ds_remoteInfo,phpAds_xmlrpcEncode,phpAds_xmlrpcDec ode,xmlrpc_entity_decode,fp,fput"

Note :- Disabling above mentioned functions may affect your web-applications, it's recommended to recheck your code & find an alternative solution, rather than risking the complete server for a mere application

[Spiral]

Chinmay, that's a little bit overkill on the disable_functions there!

Anyway, regarding the original posters question ...

Apache suEXEC on

Does this mean it is suPHP?

Just looking at what you posted alone, I can tell you that you are not
running SuPHP and that is something that would definitely be recommended
as that allows you to run all PHP scripts under the owner instead of the
generic "nobody" account of the Apache web server. This allows you to
better track script execution and closes a very serious security vulnerability
when setting up a shared hosting environment with multiple hosting accounts.

(Side FYI: Apache's suexec function is something entirely different)

There are quite a number of settings you can use in PHP.INI to further lock
down your configuration but some things such as "disable_functions" you also
need to weigh against functionality. It is a balance really between disabling
the more dangerous functions and keeping functionality for most scripts.
There are also other settings such as script execution times, upload sizes,
loadable module support, and others that you would also want to address
in your main PHP.INI file (Most are self documented within the file).

Regarding PHP security, it would also be good to install SuHOSIN which
gives you another line of defense against script exploits. This one can be
installed from EasyApache from script or WHM but is often easier and better
installed manually after your initial PHP base is built.

Unfortunately you mentioned that you are running on a VPS server so there
are some things that you won't ever be able to secure just because of the
nature of how VPS servers actually operate. Some things such as not being
able to set the server time are an irritant when it comes to VPS servers but
there are also more dangerous limitations as well which effect security.

That said though, there is still much you can do in terms of helping secure
your VPS server account but it will never be as secure as a real server!

Now remember that PHP is just one single aspect in a much bigger picture
when talking about securing your server so you also need to consider
security of the operating system and services, dangerous programs,
Apache security, disabling unused services that could be exploited as
much as possible with a VPS, installing a firewall and other defensive
programs to help monitor network traffic, keeping system core files,
libraries, and various files updated with the latest versions, etc.

If you need assistance securing your server, drop me a private
message and I will give you a hand with that.

.

What is the most secure configuration?

ADDENDUM NOTE:
-----------------
As to your specific question about the best way to operate PHP in terms of security:

The answer to that question is clearly SuPHP!

There are 3 main ways to run PHP namely Apache (DSO) Module, PhpSuExec (CGI), and SuPHP (PHP CGI called by DSO)

Apache (DSO) Module - All scripts are run as "nobody" and it is very easy to exploit cross site scripting
attacks even when user's are theoretically supposed to be restricted to their own accounts and provides
virtually no security whatsoever. Most (but not all) your main server PHP configuration settings could
be overridden with commands in your .HTACCESS files or from within scripts themselves unless disabled.

phpSuExec - This was the first attempt to close down the inherit problems of running PHP as an Apache Module
by forcing scripts to run as the account owner instead of the main Apache user (nobody). It was great in theory
but actually opened up a few even more dangerous security issues in the process. In addition, phpSuExec allowed
for custom PHP.INI files from the user's home directories which allowed for greater PHP customization per account
but also opened yet another serious avenue of security concern. To complicate matters further, phpSuExec also
had significantly slower performance running scripts than running them as an Apache module.

SuPHP - Finally comes along SuPHP which gives you the best of both worlds. The main SuPHP portion operates
as an Apache module itself and in turn calls the PHP CGI binary upon script execution which actually allows for
significantly faster execution than phpSuExec and almost as fast as running as an Apache module. Unlike phpSuExec,
running PHP from SuPHP doesn't introduce the new security concerns mentioned above that phpSuExec had brought
while still closing down the inherent problems of running directly as an Apache module. The issue of custom
configuration was also handled better as well being moved off to the server administrator's discretion allowing the
main server administrator to setup custom configurations for users for each account but not the user's themselves!
Basically in a nutshell, you get all the good things of both Apache module PHP and phpSuExec without the bad!