ServerBuddies Support Blog

PHP Security

PHP as a module or as a CGI

Using PHP as a module is suitable for systems that are dedicated to a single purpose or for sites run by trusted groups of administrators and developers. Using PHP as a CGI (possibly with an execution wrapper) is a better option when users cannot be fully trusted.

When PHP is installed as a module, it becomes a part of Apache and performs all operations as the Apache user (usually httpd).

Using PHP as a CGI

Compiling PHP as a CGI is similar to compiling it for the situation where you are going to use it as a module. This mode of operation is the default for PHP, so there is no need to specify an option on the configure line.

Migrating from a module to CGI operation, therefore, requires modifying every script.

register_globals and allow_url_fopen

register_globals. This option is off by default as of PHP 4.2.0

allow_url_fopen, allows programmers to treat URLs as files.

Because of security reasons, we turn off these options in the php.ini file:

PHP uses modules to extend its functionality dynamically. Unlike Apache, PHP can load modules programmatically using the dl( ) function from a script. When a dynamic module is loaded, it integrates into PHP and runs with its full permissions.

Use the expose_php configuration directive to tell PHP to keep quiet.

Setting this directive to Off will prevent the version number from reaching the Server response header and special URLs from being processed:

The PHP configuration directives disable_functions and disable_classes allow arbitrary functions and classes to be disabled.

The most useful security-related PHP directive is open_basedir. It tells PHP which files it can access.

Given that web server root, here is how open_basedir should be set:

When PHP is compiled with a –enable-memory-limit, it becomes possible to put a limit on the amount of memory a script consumes. Consider using this option to prevent badly written scripts from using too much memory. The limit is set via the memory_limit option in the configuration file:

You can limit the size of each POST request. Other request methods can have a body, and this option applies to all of them. You will need to increase this value from the default value specified below if you plan to allow large file uploads:

The max_input_time option limits the time a PHP script can spend processing input.

The max_execution_time option limits the time a PHP script spends running.

File uploads can be turned on and off using the file_uploads directive.

Safe mode (http://www.php.net/manual/en/features.safe-mode.php) is an attempt of\PHP developers to enhance security of PHP deployments. Once this mode is enabled, the PHP engine imposes a series of restrictions, making script execution more secure.

PHP safe mode is a useful tool. We start by turning on the safe mode:

Safe mode puts restrictions on external process execution. Only binaries in the safe directory can be executed from PHP scripts:

The following functions are affected:

• exec( )
• system( )
• passthru( )
• popen( )

Some methods of program execution do not work in safe mode:

shell_exec( ) Disabled in safe mode.
backtick operator Disabled in safe mode.
dl( ) Disabled in safe mode.

Hardened-PHP (http://www.hardened-php.net) is a project that has a goal of remedying some of the shortcomings present in the mainstream PHP distribution.

Reference - http://www.php.net

Linux Password Security with pam_cracklib

Standard Unix reusable passwords are not really a good authentication system. In an effort to address this shortcoming, the PAM module pam_cracklib was developed for Linux systems.

Enabling pam_cracklib

The pam_cracklib module is enabled via the system’s standard PAM configuration interface. On Debian systems, this is the /etc/pam.d/common-password file (but it’s /etc/pam.d/system-auth on RedHat-derived systems.

The typical configuration looks something like this:

For debian:

For Redhat:

To setup these password restrictions, edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib arguments highlighted in blue:

SUID/SGID File Security

SUID/SGID bits can be misused when the SUID/SGID executable has a security hole.

SUID stands for set user id. When a SUID file executed, the process which runs it is granted access to system resources based on the user who owns the file and not the user who created the process. When a file is SUID root it allows a program/script to perform functions that regular users are not allowed to do themselves. Many buffer overflow exploits are the result of SUID programs.

SGID stands for set group id. When looking at files SGID they behave much the same as SUID files, and must be executable for it to have any effect. The SGID bit on a directory means files created in that directory will have their group set to the directory’s group.

When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that e.g. all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.

But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you might want to search the entire system for SUID/SGID executables and document it.

To search the entire system for SUID or SGID files, you can run the following command:

The -prune option in this example is used to skip the /proc filesystem.

For example, to skip the directory `src/emacs’ and all files and directories under it, and print the names of the other files found, do something like this:

Ensure that code developers don’t set SUID/SGID bits on their programs if it’s not an absolute requirement. Very often you can use workarounds like removing just the executable bit for world/others. However, a better approach is to change the design of the software if possible.

Kernel Tunable Security Parameters

To activate the configured kernel parameters immediately at runtime, use:

The following list shows tunable kernel parameters you can use to secure your Linux server against attacks.

For each tunable kernel parameters we will show the entry that needs to be added to the /etc/sysctl.conf configuration file to make the change permanent after reboots.

Enable TCP SYN Cookie Protection

A “SYN Attack” is a denial of service attack that consumes all the resources on a machine. Any server that is connected to a network is potentially subject to this attack.

To enable TCP SYN Cookie Protection, edit the /etc/sysctl.conf file and add the following line:

Disable IP Source Routing

Source Routing is used to specify a path or route through the network from source to destination. This feature can be used by network people for diagnosing problems.

However, if an intruder was able to send a source routed packet into the network, then he could intercept the replies and your server might not know that it’s not communicating with a trusted server.

To enable Source Route Verification, edit the /etc/sysctl.conf file and add the following line:

Nessus full-service security scanner

nessus - Remote network security auditor, the client

Nessus is a full-service security scanner. The plug-in architecture of Nessus allows users to customize it for their systems and networks. As with any scanner, Nessus is only as good as the signature database it relies upon. Fortunately, Nessus is frequently updated and features full reporting, host scanning, and real-time vulnerability searches. Remember that there could be false positives and false negatives, even in a tool as powerful and as frequently updated as Nessus.

For more information about Nessus, refer to the official website at the following URL: http://www.nessus.org/

Prerequisites

Tenable recommends a minimum of 256MB of memory to operate Nessus on a local “Class C” network. To conduct larger scans of multiple networks, at least 1 GB of memory is recommended, but it can require up to 4 GB

Installation on Red Hat and SUSE

Download the latest version of Nessus from http://www.nessus.org/download/.

Nessus is available for Red Hat ES 3, ES 4, and Fedora Core 4, and SUSE 9.3 and 10.0. Unless otherwise noted, all commands should be performed as the system’s root user.

Then, install it with the following command depending on your version:

This will install Nessus into the directory /opt/nessus/.

Below is an example of the screen output for installation on Red Hat ES3:

Please run /opt/nessus/sbin/nessus-adduser to add an admin user

Register your Nessus scanner at http://www.nessus.org/register/ to obtain
all the newest plugins