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. 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] passthru – This function executes an external program and displays raw output. [php] [/php] system – This executes an external program and displays the output. [php] [/php] shell_exec – This executes the command through shell and returns the complete output as a string. [php] [/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 http://stackoverflow.com/questions/1417373/why-is-register-globals-so-bad
