There are many things to take into account when it comes to trying to secure anything not only PHP or Apache or Postfix or anything else
1. You and your users still need to be able to use it
2. The server can be as secure as possible but a few lines of bad code can really screw up your morning.
There are a few things to keep in mind when configuring the php.ini file
Firstly its probably not a bad idea to chroot your apache server, there are a few very good examples on how to do this on the web Just do a search in google or something
in your php.ini file
add the following
safe_mode = On
safe_mode_gid = Off
expose_php = Off
register_globals = Off
display_errors = Off
log_errors = On
error_log = "filename"
safe_mode = On
By switching on the safe_mode, you have just made your server probably twice as secure as it was before.
Safe mode will ensure that only the owner of the file or script is able to read or execute that file or script
Here is an example
-rw-rw-r-- 1 joeuser joeuser 33 Jul 1 19:20 script.php
-rw-r--r-- 1 root root 1116 May 26 18:01 /etc/passwd
Running this script.php
readfile('/etc/passwd');
?>results in this error when safe mode is enabled:
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /docroot/script.php on line 2
OF course we will also be logging this info to a log file rather than displaying the error
safe_mode_gid = Off
This is pretty much the same as safe_mode excepts it related directly to the GID or Group ID
If for instance we use this example, you will see how this can back fire on you if its not set to off. Although in some environments gaving GID On is fine.
-rw-rw-r-- 1 joeuser joeuser 33 Jul 1 19:20 script.php
-rw-r--r-- 1 root joeuser 1116 May 26 18:01 /usr/local/etc/passwords
Running this script.php
readfile('/usr/local/etc/passwords');
?>Because the group info is the same, I can view the passwords file even though we set safe_mode = On
Without having safe_mode_gid = Off It will not restrict me directly to the UID which is what we want effectively making the file similar to 700
expose_php = Off
Turning off the "expose_php" directive causes PHP to not show information about itself in HTTP headers that are being sent to client systems in responses to their web requests.
register_globals = Off
When the register_globals parameter is turned on, all the EGPCS (Environment, GET, POST, Cookie and Server) variables are registered as global variables, This can pose a serious security threat, it is strongly recommended to turn this parameter off if you are running an older version from 4.2.0 it has been turned off by default, but you should still double check. If an application you use requires that Register Globals be On I suggest you get it rewritten fixed etc or stop using it.
display_errors = Off
This directive will not do anything magical, however if there is a problem in the code of if the backend Database is down (if there is one) you will not see the error messages on the screen this is because we don't necessarily want someone to see too much information like that user root@localhost can't log into the database and the data base is called jacks-db, Im sure you can see where I am going with this.
log_errors = On
Simply put we want to log our errors
where we log them will be defined in the next directive
error_log = "filename"
error_log = /var/log/php-errors/php.log
Or something like that its up to you
You might also want to check this out
disable_functions = phpinfo, curl_exec, curl_init, passthru, show_source, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, system
This stops PHP scripts from using these functions you might need some of them but your average web site or even web based application probably would not need these.
1. You and your users still need to be able to use it
2. The server can be as secure as possible but a few lines of bad code can really screw up your morning.
There are a few things to keep in mind when configuring the php.ini file
Firstly its probably not a bad idea to chroot your apache server, there are a few very good examples on how to do this on the web Just do a search in google or something
in your php.ini file
add the following
safe_mode = On
safe_mode_gid = Off
expose_php = Off
register_globals = Off
display_errors = Off
log_errors = On
error_log = "filename"
safe_mode = On
By switching on the safe_mode, you have just made your server probably twice as secure as it was before.
Safe mode will ensure that only the owner of the file or script is able to read or execute that file or script
Here is an example
-rw-rw-r-- 1 joeuser joeuser 33 Jul 1 19:20 script.php
-rw-r--r-- 1 root root 1116 May 26 18:01 /etc/passwd
Running this script.php
readfile('/etc/passwd');
?>results in this error when safe mode is enabled:
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /docroot/script.php on line 2
OF course we will also be logging this info to a log file rather than displaying the error
safe_mode_gid = Off
This is pretty much the same as safe_mode excepts it related directly to the GID or Group ID
If for instance we use this example, you will see how this can back fire on you if its not set to off. Although in some environments gaving GID On is fine.
-rw-rw-r-- 1 joeuser joeuser 33 Jul 1 19:20 script.php
-rw-r--r-- 1 root joeuser 1116 May 26 18:01 /usr/local/etc/passwords
Running this script.php
readfile('/usr/local/etc/passwords');
?>Because the group info is the same, I can view the passwords file even though we set safe_mode = On
Without having safe_mode_gid = Off It will not restrict me directly to the UID which is what we want effectively making the file similar to 700
expose_php = Off
Turning off the "expose_php" directive causes PHP to not show information about itself in HTTP headers that are being sent to client systems in responses to their web requests.
register_globals = Off
When the register_globals parameter is turned on, all the EGPCS (Environment, GET, POST, Cookie and Server) variables are registered as global variables, This can pose a serious security threat, it is strongly recommended to turn this parameter off if you are running an older version from 4.2.0 it has been turned off by default, but you should still double check. If an application you use requires that Register Globals be On I suggest you get it rewritten fixed etc or stop using it.
display_errors = Off
This directive will not do anything magical, however if there is a problem in the code of if the backend Database is down (if there is one) you will not see the error messages on the screen this is because we don't necessarily want someone to see too much information like that user root@localhost can't log into the database and the data base is called jacks-db, Im sure you can see where I am going with this.
log_errors = On
Simply put we want to log our errors
where we log them will be defined in the next directive
error_log = "filename"
error_log = /var/log/php-errors/php.log
Or something like that its up to you
You might also want to check this out
disable_functions = phpinfo, curl_exec, curl_init, passthru, show_source, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, system
This stops PHP scripts from using these functions you might need some of them but your average web site or even web based application probably would not need these.
Comments