Hacker proofing Apache & PHP configuration

SECURING APACHE

Apache has been truly one of the dominant web servers of the World Wide Web. It's one of the best open source projects, Web Server for both the Windows and the NIX platform. It's maintained by the open source community under the name Apache Software Foundation. Now first we will learn about the techniques to how harden our Apache configuration for a safer web experience.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Security 101- DENY ALL

Always remember it's the best security to deny all and only allow specific services, ports and firewall rules as per the configuration. So the same goes for Apache as well, we follow a whitelisting technique to deny all and only allow what is required. Hence what we have done here is to block access to all the directories. These configurations and changes have to be done in the main configuration file of Apache, or if you are using a newer version of Ubuntu/ Backtrack r3 they can be found under/etc/apache2/conf.d/security

Now let's allow what we really require, access to a particular folder XYZ. So we make some more changes to the configuration file.

Security 102- Disabling Directory Indexing

This vulnerability basically displays all the files in a particular directory, if the base file like index.php index.html is not available. On a few default configurations it's enabled by default and causes the exploit. We can remove this by:

Security 103- Disable HTTP TRACE Method

Now TRACE method simply echoes back the received request for a client so that he may see what changes or additions have been done. Attackers can abuse this functionality to gain access to sensitive information via headers like cookies and authentication data. This may be disabled by:

Security 104- Removing the default files

Having the default files of Apache in a live web server environment is really bad. These may be used to fingerprint the apache version and even the operating system at times. This ultimately helps to obfuscate our running web server.

Security 105 – Disable server tokens and signatures

It's a good security practice to disable server signatures

Security 106 – Remove Default Error Pages

It's a good security practice to remove default error pages offered by Apache. This ultimately makes it difficult for the attackers to identify what web server or version you're running on. Hence it's advised to create custom pages for errors, bugs and functionality problems in a particular application.

Security 107 – Disable WebDAV

WebDAV stands for Web Distributed Authoring and Versioning which aids in the download/upload of files and the ability work with those files on a remote web server. It's basically required to run a SVN server, hence it would be advisable to disable WebDAV in online websites due to the high denial vulnerability of service attacks via PROFIND, PROPATCH or LOCK requests with a huge XML body.

Here is how we remove/disable WebDAV:

Security 108 – Setup a chroot environment for your website

Chroot is a process to change the apparent disk root to another root directory. Hence once we have changed the root to another directory we cannot access files outside that particular directory. It's also known as a jailed environment/chroot jail. So when working in a chroot environment an application is inaccessible to the parent disk and other resources. This is a security practice because helps protect from malicious users of hosted websites on the server from accessing the operating system's files. Such similar instances may be created for different websites hosted on the same server which, blocks access of malicious scripts/virus from one site to the other.

Security 109 – Distribute Ownership and don't be Root

It is recommended to avert from running Apache as a root user since malicious users may gain full access to the whole server by using potential bad scripts. If the webserver hosts a multiple number of sites then files for different sites should be owned by different users. This ultimately helps in preventing access from one site to another so, if one gets infected the others are safe.

Security 110 – Don't forget to install security updates

It's best advised to install security updates and patches which may be released by the organization for fixes against some vulnerabilities. This prevents our server from being susceptible to the same exploits from open disclosure sites.

Securing PHP

Now let's move to securing our PHP configuration to prevent various server side attacks, which may be possible if left insecure.

Security 101 – Disable PHP information

It is recommended to disable PHP information to the outside world since it helps us protect the current version of PHP we run from the outside world. If the PHP information is turned there can be instances in which the PHP version may be seen in the HTTP headers.

Here is how we disable it:

Security 102- Log all Errors

It is always advised to log all PHP errors and avoid them from being displayed. Here is how to do it:

Security 103- Disallow File Uploads

All types of file uploads should be disabled by default. If the application requires certain files to be uploaded then it should be thoroughly checked for proper extensions, parsed for malicious scripts and kept in a sandboxed location. All external data should be treated as unsafe and should not be trusted upon.

Here is how to do it:

Security 104 – Disallow Remote Code Execution

This option if enabled allows the website to retrieve data from a remote website through include etc. It may allow an attacker to inject malicious URLs from his websites and include/parse it through the local PHP interpreter for a command execution. Hence this is important to prevent against code injection vulnerabilities. It's also advised to filter any inputs which are to be received from users.

Here is how we do it:

Security 105 – Disabling Privileged Functions

There is a long list of PHP functions which should be disabled to protect the PHP configuration. The functions are-

exec – This is used for executing an external command.

[php]

<?php

echo exec('ls -A');

?>

[/php]

passthru – This function executes an external program and displays raw output.

[php]

<?php

echo passthru('ls -A');

?>

[/php]

system – This executes an external program and displays the output.

[php]

<?php

echo system('ls');

?>

[/php]

shell_exec – This executes the command through shell and returns the complete output as a string.

[php]

<?php

echo shell_exec('ls');

?>

[/php]

proc_open – This executes a command and opens file pointers for input/output

proc_close – This closes a process opened up by proc_open and returns the exit code of that process.

popen- This basically opens a pipe to the program specified in the command interpreter.

Few other functions which should be disabled are curl_exec,curl_multi_exec,parse_ini_file,show_source

Here is how we do it:

Security 106 – Limit PHP access to file system

In most web server setups it's strictly advised that the web applications are not allowed to read files outside of the web root directory. All the web server files are generally located under /var/www unless a customization is done. Hence we restrict the PHP applications to act outside this directory by using the open_basedir as shown below:

Security 107 – Turning on Magic Quotes

The magic quotes features gives PHP the ability to automatically escape quotes, backslashes and Nulls with a backslash. Hence it filters any unwanted quotes which might have been passed by a malicious user to the application. This might prevent XSS, SQL injection and some other attacks by the malicious user.

Security 108 – Disabling Register Globals

This directive takes input from GET, POST, session variables, uploaded files, which are directly accessible as global variables. Suppose we have a URL

http://www.example.com/xyz.php?input=TRUE

It has a query string at the end of the URL, now any value entered will directly affect the value of the variable. Hence it will allow any malicious user to inject any global variable in the code without any control.

The easiest method to do this would be to include a line in the .htaccess file.

php_flag register_globals off

References

http://www.techrepublic.com/blog/doityourself-it-guy/diy-harden-apache-web-servers-with-these-tips/482

http://xianshield.org/guides/apache2.0guide.html

http://www.kyplex.com/docs/apache-security.html#_

http://www.cyberciti.biz/tips/php-security-best-practices-tutorial.html

http://stackoverflow.com/questions/6470760/dangerous-php-functions

http://php.net/manual/en/ref.exec.php

http://www.w3schools.com/php/func_filesystem_popen.asp

http://www.tenable.com/blog/configuration-auditing-phpini-to-help-prevent-web-application-attacks

https://www.owasp.org/index.php/Configuration#PHP_Configuration

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

http://stackoverflow.com/questions/1417373/why-is-register-globals-so-bad