Apache Web Server Security

The increase in cyber attacks on high profile online business websites implies that web security still needs to be addressed. Exploits of web server vulnerabilities typically have a more disastrous and visible impact. While with web application vulnerabilities a malicious user could gain access to a database and other form of stored data, with web server software vulnerabilities, a malicious user could even gain access to the operating system, potentially compromising the whole network.

A brief introduction to Apache web server

The Apache Foundation released Apache Version 2 in 2002, following on the success of Apache Web Server version 1. Version 2 was almost a total rewrite, which mostly focused on further modularization and development of the Apache core. Apache Version 2 has several improvements, which include Unix threading, IP version 6 support and most importantly of all, better support for non-Unix platforms, such as Microsoft Windows. These improvements helped Apache web server to become the first web server used to host over 100 million websites and web applications on the internet, thus being the most widely used web server.

Securing Apache web server

The following suggestions will go a long way in improving the security of an Apache web server installation. Despite applying the ‘less is better’ rule to harden a web server by disabling a number of modules, it will not be enough. It is still recommended to apply all security patches in case a disabled module is enabled in the future.

Limit server functionality

One must first be aware of which function or functions the web server will be used for. Will it serve HTML pages only, or also execute a number of scripts? Enabling support for PHP, ASP.NET and other similar web technologies will only increase the attack surface which a malicious user could penetrate. This might happen because of vulnerabilities in a specific web server module. Therefore one should only support web technologies which are going to be used.

Limit access to operating system and its files

The operating system on which the Apache web server will be running must also be hardened. For more information on how to secure a web server operating system, click here. It is important that the Apache web server process runs under a unique user ID, which must not be used by any other system processes. Apache processes must also have limited access to the operating system files (chrooting). Chrooting is the process of creating a new root directory structure where all Apache daemon files are moved to. As a result of the chrooting process, the Apache web server daemon will only have access to the new directory structure. No shell programs e.g. /bin/sh, /bin/csh/ should be present in the Apache’s chrooted environment. This way the web server benefits immunity from a large number of existing exploits.

Disable unnecessary web server modules

Apache is shipped with a number of pre-enabled modules to be more user friendly. This is a bit of a break from its Unix past of only providing the essential. In this case, the ‘less is better’ rule is to be applied with more diligence and the choice of which module to enable is probably the most important step. An administrator would avoid potential break-ins simply by disabling unnecessary modules when new vulnerabilities are found in them. Check about every pre-enabled module to confirm if it is needed, and if not, disable it.

Tighten the Apache configuration

The default Apache configuration contains a large number of directives that are not used in a typical scenario. One can safely switch off or disable the directives listed below if not being used:

• directory indexes
• unnecessary default ‘Alias’ and 'ScriptAlias’
• Handlers (only leave handlers which you will be using. Remove all others)
• Directory Options such as ‘FollowSymLinks’ (if no symbolic links are used in the web directories)

Friendly web server error messages should also be configured, to make sure that the least amount of information is disclosed about the Apache web server installation and configuration. If possible, the web server banner should also be obfuscated (security by obscurity).

Disable Server Sides Includes

SSIs bring along a number of potential security risks with them. Most important of all, SSI-enabled web documents will severely increase the load on the server. In high traffic websites or in a shared web hosting environment, such load can become very significant. Furthermore, server sides includes pose the same number of risks associated with CGI (Common Gateway Interface) scripts in general. SSI-enabled files, can execute any CGI script or program under the permissions of the user which the Apache web server runs on, thus posing a huge security risk. A number of web technologies that avoid using SSI and transfer the processing required to the client / browser side are available today. A web master should take advantage of such web technologies.

Monitor log files

Proper web application access and web server operation logging should be enabled. Such logs should not be placed in the web server root directory. As with any other internet service, it is important to check all of Apache’s log files regularly. Analysing past events from web server log files, will give the administrator a good idea of what attack trends are being followed. This will also help the administrator identify where the web server needs tightening up.

Install all Apache web server updates

From time to time, Apache Foundation release a number patches. It is always a good practice to keep the Apache web server installation up to date, despite of whether the patch is a security patch, or a software update. Subscribe to a mailing list such as ‘Apache Server Announcements’ to receive notifications of when updates and patches are available. Such mailing lists are hosted by the Apache Foundation.

Stay informed and frequently check the web server configuration

A number of books, online security guidelines articles and white papers are available to help an administrators secure an Apache web server installation and implement the above security suggestions, which are however universal. It is suggested to read such articles and follow the guidelines. After applying such changes, it is also important to test the web server’s and web application’s functionality, to confirm that such changes did not hinder any of the web application’s functionality. The use of third party security tools, such as Acunetix WVS can help confirm that the applied procedures did improve your web server security. Acunetix WVS will also launch a number of security checks against an Apache web server, and will also check for weak configurations. Take a product tour of Acunetix Web Vulnerability Scanner or download it today!